An authentication method and system supporting mutual recognition between multi-data space standards

Abstract

The application discloses an authentication method and system supporting mutual authentication between multiple data space standards, and relates to the technical field of data space authentication. In the application, an authentication attribute set is extracted from an authentication request of a first data space standard through a preset semantic library, and an intermediate semantic representation is generated, which is carried by a common field set and can express authentication requirements of multiple standards at the same time. Based on a preset mapping strategy library, the intermediate semantic representation is converted into an authentication instruction conforming to a second data space standard, and the strength level of a source request and the target instruction is compared by using an authentication strength level system. The authentication instruction is executed only when the target strength level is not lower than the source strength level, and a response conforming to the first data space standard is generated and returned to the initiator. The application can realize bidirectional peer authentication conversion between different data space standards without reducing the original security level, improve cross-standard authentication efficiency and system compatibility, and provide a reliable basis for cross-border and cross-domain data circulation.

Description

Technical Field

[0001] This invention relates to the fields of data security, data space interconnection and cross-domain identity authentication, and in particular to an authentication method and system that supports mutual recognition between multiple data space standards. Background Technology

[0002] With the advancement of market-based allocation of data elements, trusted data spaces have become a critical infrastructure for secure data sharing across organizations and regions. The reference architecture and data space protocol proposed by the International Data Space Association (IDSA) have been widely adopted globally and have become mainstream international standards. Meanwhile, my country is also actively building a trusted data space standard system that meets domestic data governance requirements to support the compliant flow of data elements.

[0003] In cross-domain data flow, different data spaces often employ heterogeneous authentication mechanisms. Taking the IDSA standard as an example, authentication between connectors typically involves two stages: bidirectional mTLS connection establishment and Dynamic Attribute Token (DAT) verification. In contrast, domestic trusted data space standards usually employ challenge-response, certificate chain verification, subject state verification, and derived symmetric tokens. Due to fundamental differences between the two standards in authentication credential formats, security models, permission expressions, and authentication strength determination, direct, secure, and mutually trusting authentication interoperability between trusted data spaces based on different standards is difficult to achieve.

[0004] To address the aforementioned issues, existing technologies primarily employ two approaches. One is the independent authentication gateway model: This involves deploying separate authentication gateways for international and domestic data spaces, requiring data to pass through two independent authentication systems and complete two full authentication processes. This approach results in lengthy authentication links, high latency, and the interconnectedness of multiple gateways reduces system stability and success rate. The other is the one-way protocol conversion model: This model uses one standard as the primary standard and converts the authentication requests and credentials of another standard into a format recognizable by the local standard through hard-coded rules. This approach essentially assimilates the external standard into an internal one, failing to achieve true bidirectional, peer-to-peer mutual recognition. Furthermore, when any standard version evolves, the hard-coded rules must be manually modified item by item, leading to high maintenance costs and poor scalability.

[0005] In addition, the existing solutions have the following shortcomings: (1) Lack of security: Simple field translation or format conversion often destroys the security assumptions of the original standard protocol, resulting in the loss of key security contexts such as identity binding relationship, authentication strength, permission boundary and validity period, making it difficult to pass the compliance audit of both standards. (2) Lack of security level control: The existing solutions usually only verify whether the credential is legal, without quantifying the authentication strength of the source credential and the target credential, and there is no constraint and alarm mechanism for the security level not to be downgraded. (3) Weak anomaly handling capability: When semantic mapping fails, DAPS service is unavailable, certificate chain is abnormal or the target standard cannot meet the security requirements of the source standard, the existing technology lacks a unified failure handling, error code classification and audit closed loop.

[0006] Therefore, there is an urgent need for a two-way, peer-to-peer, secure, and scalable authentication and mutual recognition method that can support international and domestic data space standards, in order to solve the fundamental problems of low authentication efficiency, poor interoperability, lack of security, and high maintenance costs in existing technologies. Summary of the Invention

[0007] To address the problems existing in the prior art, the main objective of this invention is to provide an authentication method and system that supports mutual recognition between multiple data space standards. This method and system can achieve bidirectional peer-to-peer authentication conversion between different data space standards without reducing the original security level, and supports flexible adaptation during standard version evolution and industry expansion.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides an authentication method supporting mutual recognition of multiple data space standards, comprising the following steps: Obtain the authentication request from the initiator that conforms to the first data space standard; Extract the authentication attribute set carried in the authentication request, and generate an intermediate semantic representation based on a preset semantic library and a preset set of public fields; wherein the set of public fields can cover the authentication description requirements of the first data space standard and the second data space standard; Based on a pre-built mapping strategy library, the intermediate semantic representation is converted into authentication instructions that conform to the second data space standard; Based on a preset authentication strength level system, the source strength level corresponding to the authentication request and the target strength level corresponding to the authentication instruction are determined, and the authentication instruction is executed only when the target strength level is not lower than the source strength level. After obtaining the authentication result of the second data space standard, a response conforming to the first data space standard is generated and returned to the initiator.

[0009] As a preferred embodiment, the semantic library is constructed by combining at least two of the following: a basic ontology model, a standard mapping table, an industry-specific extended lexicon, and a version index; wherein... The basic ontology model is used to define the common semantics of identity subjects, connectors, trust anchors, authentication strength, permission types, validity periods, usage restrictions, and transmission certificate bindings; The standard mapping table is used to maintain the equivalence, inclusion, mutual exclusion, or conditional mapping relationships between the terms of the first data space standard and the fields of the second data space standard. The industry-specific extended thesaurus is used to adapt to the differentiated terminology of different industries; The version index is used to distinguish the mapping definitions under different standard versions, different industry versions, and different deployment tenants. Each version record includes a standard identifier, standard version number, industry identifier, effective time, expiration time, compatibility range, and rollback version number.

[0010] As a preferred embodiment, determining the source strength level corresponding to the authentication request includes: determining the source strength level based on the authentication attribute set carried in the authentication request; Determining the target strength level corresponding to the authentication instruction includes: estimating the target strength level based on the authentication elements invoked by the authentication instruction; The preset certification strength level system includes five levels from L1 to L5: Level L1 represents single static credential verification; Level 2 indicates single certificate chain verification; Level 3 indicates a certificate chain plus challenge-response verification; Level 4 indicates a certificate chain plus dynamic tokens or two-factor authentication; The L5 level indicates that the certificate chain, dynamic token, subject state, usage constraints, and transport bindings have all been verified.

[0011] As a preferred embodiment, the intermediate semantic representation is expressed using a structured JSON-LD object or an RDF triple set, and the authentication attribute set includes at least one of the following: identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, transmission binding information, random number relationship, and proof chain information; The random number relationship field is used to record the correspondence between the initiator's random number and the target's random number. When the first data space standard or the second data space standard is a domestic trusted data space standard, the value of the random number relationship field is extracted from the challenge response process. When the first data space standard or the second data space standard is an international data space standard, the random number relationship field is empty or missing.

[0012] As a preferred solution, the mapping strategy library supports hot updates, and the mapping engine loads the strategy after it is published without restarting the service. The mapping policy library adopts the following priority and conflict resolution rules: precise standard version policies take precedence over general policies, industry-specific policies take precedence over cross-industry policies, and explicit security restrictions take precedence over permission relaxation rules. If multiple rules are matched simultaneously and conflict, the result with higher security level, narrower permission scope, and shorter validity period will be selected. If the conflict still cannot be resolved, the mapping will be rejected and an alarm will be output. Furthermore, the authentication instruction is executed only when the target strength level is not lower than the source strength level; otherwise, a fallback mechanism is triggered. The fallback mechanism includes one or more of the following: switching to a target policy that is more stringent than the current mapping policy; Additional verification steps are added before executing the authentication instruction; The initiator is required to reapply for a higher-level certificate before proceeding with the authentication.

[0013] As a preferred embodiment, generating a response conforming to the first data space standard includes: The generated intermediate semantic representation, as well as the context transaction identifier and proof chain information generated during the authentication process, are reused. For fields in the authentication results of the second data space standard that already exist in the first data space standard, the corresponding values ​​are preferentially read from the reused intermediate semantic representation; For the newly added fields in the authentication results of the second data space standard, they are converted into authentication result descriptions, session states, or subsequent call credentials that can be recognized by the first data space standard according to the preset reverse mapping rules; wherein, the reverse mapping rules and the forward mapping rules in the mapping strategy library form a reversible correspondence. The read corresponding value, along with the converted authentication result description, session status, or subsequent call credentials, are encapsulated into a response message conforming to the first data space standard.

[0014] As a preferred embodiment, when the first data space standard is the international data space standard, the authentication request is a Hypertext Transfer Security Protocol request established on a bidirectional transport layer security session, and the authentication request carries a dynamic attribute token. The set of authentication attributes carried in the authentication request includes: The issuer, token endpoint, and JSON Web Key Set Uniform Resource Identifier are determined based on the server metadata published by the dynamic attribute provisioning service; the issuer, audience, expiration time, effective time, scope, security profile, reference connector, and transport certificate secure hash algorithm 256 declaration of the dynamic attribute token are verified; the identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, and transport binding information are extracted from the dynamic attribute token and the bidirectional transport layer secure session as the authentication attribute set; or... When the first data space standard is a domestic trusted data space standard, the authentication request is a challenge-response interface request. The authentication request carries verification parameters encrypted with the target party's public key. The verification parameters include at least the initiator's random number and the initiator's certificate. The set of authentication attributes carried in the authentication request includes: The verification parameters are decrypted to obtain the initiator's random number and initiator's certificate; the initiator's certificate is subjected to certificate chain verification; the subject identity status service is queried to obtain the subject identity status corresponding to the initiator's certificate; the signature result returned by the initiator is received, and the correspondence between the signature result and the initiator's random number is verified; the identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, random number relationship, and proof chain information are extracted from the encrypted relationship between the initiator's certificate, the certificate chain verification result, the subject identity status, the signature result, and the subsequently returned token as the authentication attribute set.

[0015] As a preferred embodiment, when the second data space standard is an international data space standard, the step of converting the intermediate semantic representation into an authentication instruction conforming to the second data space standard includes: Generate instructions to establish a bidirectional transport layer secure session, specifying the client certificate and trust store; generate instructions to request a dynamic attribute token from the token endpoint of the dynamic attribute provisioning service, wherein the request method is a client credential authorization type, and generate a client assertion; generate instructions to verify the returned dynamic attribute token, the verification including verifying the issuer and metadata consistency, verifying the signature, verifying the validity period and audience, and verifying the binding of the transport certificate secure hash algorithm 256 with the bidirectional transport layer secure session certificate; generate instructions to append the dynamic attribute token to the target connector request; or, When the second data space standard is a domestic trusted data space standard, the step of converting the intermediate semantic representation into an authentication instruction conforming to the second data space standard includes: Generate a challenge interface call instruction, which carries verification parameters encrypted with the target party's public key, the verification parameters including the initiator's random number and initiator's certificate extracted from the intermediate semantic representation; generate a response interface call instruction, which carries a signature result and encryption algorithm identifier; generate an instruction to derive a symmetric encryption salt and obtain a token; The authentication instruction includes fields for desired permissions and security level requirements.

[0016] As a preferred solution, an exception handling process is also included: When no concept in the authentication request can be matched in the semantic library, the authentication is interrupted and a semantic misalignment error code is returned, along with the identifier of the unmatched concept. When the mapping policy library is unable to convert the intermediate semantic representation into the authentication instruction, the authentication is interrupted and a policy incompatibility error code is returned. When the target strength level is lower than the source strength level and the fallback mechanism cannot be executed, authentication is interrupted and a security level downgrade error code is returned, and an alarm is triggered. When certificate chain verification fails, subject status verification fails, dynamic attribute provisioning service metadata is unavailable, dynamic attribute token signature is invalid, random number relationship does not match, or timestamp verification fails, the corresponding standardized error code is returned and written to the audit log. The audit log shall at least record the semantic alignment results, rule hit records, security level determination basis, target standard execution process, and error codes.

[0017] In a second aspect, the present invention provides a two-way authentication system that supports mutual recognition between different data space standards, comprising: a protocol conversion and semantic alignment layer, used to obtain an authentication request conforming to a first data space standard from the initiator; and used to extract the authentication attribute set carried in the authentication request and generate an intermediate semantic representation based on a preset semantic library and a preset set of public fields; wherein the set of public fields can cover the authentication description requirements of the first data space standard and the second data space standard; The authentication mapping and execution layer is used to convert the intermediate semantic representation into an authentication instruction conforming to the second data space standard based on a preset mapping strategy library; to determine the source strength level corresponding to the authentication request and the target strength level corresponding to the authentication instruction according to a preset authentication strength level system, and to execute the authentication instruction only when the target strength level is not lower than the source strength level; and to generate a response conforming to the first data space standard after obtaining the authentication result of the second data space standard, and return it to the initiator.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) In this invention, a pre-built semantic library and mapping strategy library, combined with an intermediate semantic representation and an authentication strength level system, enable bidirectional peer-to-peer authentication conversion between different data space standards. Specifically, an authentication attribute set is extracted from the authentication request of the first data space standard to generate an intermediate semantic representation that is carried by a set of common fields and can simultaneously express the authentication requirements of multiple standards, thus unifying the authentication information of heterogeneous standards into the same semantic layer. Then, based on the mapping strategy library, the intermediate semantic representation is converted into an authentication instruction that conforms to the second data space standard, forming a complete bidirectional conversion closed loop. In this process, an authentication strength level system is introduced to determine the strength level of the source request and the target instruction respectively. Authentication is only performed when the target level is not lower than the source level, quantifying and forcibly maintaining the security level without degradation. Based on the above architecture, when the standard version evolves or the industry expands, only the semantic library or mapping strategy library needs to be updated without modifying the core logic, thereby significantly improving the efficiency of cross-standard authentication and system compatibility, realizing efficient interoperability of cross-standard authentication, no degradation of security level, scalable system maintenance, and bidirectional real-time verification between international and domestic standards, providing a reliable foundation for cross-border and cross-domain data circulation.

[0019] (2) In this invention, the semantic library is further configured as a multi-dimensional versionable architecture. The basic ontology model provides an upper-level conceptual framework that transcends standard differences, enabling the conceptual systems of different standards to be aligned in the same semantic space. The standard mapping table establishes equivalence, inclusion, or conditional mappings between specific terms, realizing precise conversion from concepts to fields. The industry-extended thesaurus enables the knowledge graph to be differentiated by domain without interfering with each other. The version index and rollback mechanism enable the semantic library to have the ability to evolve in the time dimension. The system selects the semantic library according to the precise version priority, industry priority, and general fallback, so as to automatically select the most suitable context when there are multiple potential semantic interpretations, and realize the support for intelligent matching of cross-standard authentication.

[0020] (3) In this invention, furthermore, by establishing an authentication strength level system from L1 to L5, the authentication elements of different standards are abstracted into comparable security metrics. Through the quantification of the combination of verification elements, a unified comparison of cross-standard security strength is achieved, solving the problem that traditional solutions cannot determine whether there is a security equivalence relationship between IDSA's mTLS plus DAT and the challenge-response plus certificate chain of domestic standards. Simultaneously, by separating authentication strength from specific implementations, the high-strength authentication of the source standard will not be replaced by the low-strength authentication of the target standard, thus establishing a formal criterion for security equivalence at the decision-making level.

[0021] (4) In this invention, the mapping strategy is further designed as a hot-updateable rule base, and a security-first conflict resolution mechanism is built-in. The evolution of the standard version is no longer a system upgrade event, but a configuration change of the strategy base. Precise version priority ensures accurate adaptation to the new standard, industry priority preserves domain specificity without breaking general rules, and automatic selection of stricter constraints in case of conflict reflects the design principle of uncompromising security. The fallback mechanism further expands the single rejection due to security non-compliance into multi-path recovery, enabling the system to complete legitimate authentication through upgrade strategy or supplementary verification when facing security degradation risks. Overall, a maintainable and evolvable security strategy governance framework is constructed.

[0022] (5) In this invention, furthermore, cross-standard authentication is achieved through intermediate semantic representation. Each field in the intermediate semantic representation corresponds to a core security proposition in authentication: identity identifier answers "who is it", credential type answers "what is used to prove it", trust anchor answers "who guarantees it", authentication strength answers "how reliable it is", authorization information answers "what it can do", validity period answers "until when", transmission binding answers "who it communicates with", random number relationship answers "whether it is fresh", and proof chain answers "how to verify it". These propositions cover all the intersections and differences between IDSA and domestic standards in terms of security assumptions.

[0023] (6) In this invention, intermediate semantic representations and proof chain information are cached during the forward phase and directly reused instead of being re-parsed during the reverse phase. This not only avoids the latency caused by repeated calculations, but more importantly, it ensures the consistency between the forward authentication conclusion and the reverse response. This design realizes the two-way authentication closed loop from the conceptual level to an engineering-feasible lightweight solution.

[0024] (7) Furthermore, this invention also includes an exception handling process. This process models the authentication decision chain for interpretability: semantic misalignment corresponds to missing concepts, policy incompatibility corresponds to rule conflicts, security level downgrade corresponds to insufficient strength, and various verification failures correspond to specific technical link anomalies. Each type of error is accompanied by locatable information, and the audit log fully records the reasoning chain—which rule was hit, how the level was determined, which steps were executed, and what error occurred. This makes authentication failure no longer a black box, and operations and maintenance personnel can directly locate the missing concepts in the semantic library or the conflicting rules in the policy library. These traceable and interpretable exception records constitute the evidence chain proving the correctness of the system's security decisions. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating an authentication method supporting mutual recognition of multiple data space standards according to an embodiment of the present invention. Figure 2This is a functional block diagram of an authentication system supporting mutual recognition of multiple data space standards according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating an embodiment of the present invention. Figure 4 This is a flowchart illustrating an embodiment of the present invention, Example 2.

[0026] Figure label: Detailed Implementation

[0027] To better illustrate the objectives, technical solutions, and advantages of the present invention, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0028] like Figure 1 As shown, this embodiment of the present invention provides an authentication method supporting mutual recognition of multiple data space standards. This method is used to achieve bidirectional, peer-to-peer authentication conversion between different data space standards. For ease of description, the standard followed by the party initiating the authentication request is referred to as the first data space standard, and the standard followed by the party receiving the authentication conversion instruction is referred to as the second data space standard.

[0029] In this embodiment, a pre-defined semantic library is used to store the correspondence between authentication semantics and intermediate semantic representations for different data space standards. A pre-defined mapping strategy library is used to store the mapping rules between intermediate semantic representations and authentication instructions for different data space standards. A pre-defined authentication strength level system is used to quantify the security strength of different authentication methods, and it includes multiple levels from low to high.

[0030] The method in this embodiment includes the following steps.

[0031] S1. Obtain an authentication request from the initiator that conforms to the first data space standard.

[0032] In this embodiment, an authentication request is received from the initiating data space connector. The authentication request carries authentication credentials, identity identifiers, and permission semantics conforming to the first data space standard. Differentiated authentication request entry points are designed for different data space standards. The request entry point identifies the specific type of the first data space standard to obtain the authentication request corresponding to that standard.

[0033] For example, when the first data space standard is the International Data Space Standard, the request entry point is a Hypertext Transfer Security (HTTPS) request established on a bidirectional Transport Layer Security (mTLS) session, and the authentication request carries a Dynamic Attribute Token (DAT). The system determines the issuer, token endpoint, and JSON Web Key Set Uniform Resource Identifier (jwks_uri) based on the server metadata published by the Dynamic Attribute Provisioning Service (DAPS); and verifies the issuer, audience, expiration time, effective time, scope, security profile, reference connector, and transport certificate secure hash algorithm 256 declaration of the dynamic attribute token.

[0034] For example, when the first data space standard is the domestic trusted data space standard, the request entry point is the challenge-response interface request, and the authentication request carries verification parameters encrypted with the target party's public key. The verification parameters include at least the initiator's random number and the initiator's certificate.

[0035] S2. Extract the authentication attribute set from the authentication request, and generate an intermediate semantic representation based on a preset semantic library and a preset set of public fields; wherein the set of public fields can cover the authentication description requirements of the first data space standard and the second data space standard.

[0036] Specifically, the authentication attribute set consists of fields and their values ​​extracted from authentication requests based on the first data space standard, representing core security claims, identity identifiers, and permission semantics. Core security claims refer to key security facts in the authentication request that directly determine the trustworthiness of the request and are related to credentials and the chain of trust, including credential type, trust anchor, proof chain information, authentication strength (authnLevel), and security profile. Identity identifiers are information in the authentication request that identifies the requesting subject, including identity and subject identifier. Permission semantics refers to semantic information carried in the authentication request related to authorization, access control, and usage restrictions, including privilege set, validity period, transport binding information, nonce relation, and audience.

[0037] Based on the authentication attribute set, a pre-defined semantic library is queried. Illustrated, the semantic library contains common semantics for abstracting identity subjects, connectors, trust anchors, authentication strength, permission types, validity periods, usage restrictions, and transmission certificate binding. The semantic library also contains equivalence, inclusion, mutual exclusion, or conditional mapping relationships between fields of the first and second data space standards, covering the basic authentication description requirements of both standards. The query results generate an intermediate semantic representation according to the pre-defined set of common fields. In other words, the intermediate semantic representation is the field values ​​of the pre-defined set of common fields. The set of common fields can simultaneously express the authentication requirements of both the first and second data space standards, and the intermediate semantic representation can characterize the core security claims, identity identifiers, and permission semantics of the authentication request. However, the set of common fields and the intermediate semantic representation are independent of specific data space standards, thus normalizing authentication information from different standards to a unified semantic level.

[0038] S3. Based on a pre-set mapping strategy library, the intermediate semantic representation is converted into authentication instructions that conform to the second data space standard.

[0039] Specifically, based on the intermediate semantic representation generated in step S2, a pre-defined mapping strategy library is queried. The mapping strategy library contains mapping rules that match the field values ​​in the intermediate semantic representation with the authentication instructions of the target data space standard. The authentication instructions, after converting the intermediate semantic representation, are a sequence of operations that can be executed by the authentication engine under the second data space standard.

[0040] For example, international data space standards include instructions for establishing bidirectional transport layer secure sessions and instructions for requesting dynamic attribute tokens from dynamic attribute providers. Domestic trusted data space standards include challenge interface call instructions and response interface call instructions.

[0041] S4. Based on the preset authentication strength level system, determine the source strength level corresponding to the authentication request and the target strength level corresponding to the authentication instruction, and execute the authentication instruction only when the target strength level is not lower than the source strength level.

[0042] Specifically, the authentication strength level system is a standardized grading model that quantitatively assesses the security strength achieved by different authentication methods or credentials (i.e., different digital space standards). The source strength level is determined based on the combination of verification elements reflected in the authentication attribute set in the authentication request of the first digital space standard. The target strength level is estimated based on the authentication elements invoked by the authentication command of the second digital space standard. The authentication command is executed only if the target strength level is not lower than the source strength level.

[0043] If the target strength level is lower than the source strength level, a fallback mechanism is triggered, such as switching to a stricter target policy, adding extra verification steps, or requiring the initiator to reapply for a higher-level credential.

[0044] S5. After obtaining the authentication result of the second data space standard, generate a response that conforms to the first data space standard and return it to the initiator.

[0045] In this embodiment, the first data space standard and the second data space standard are relatively interchangeable. When the initiator adopts the international data space standard and the target adopts the domestic trusted data space standard, this method executes steps S1 to S5 above to achieve authentication conversion from international to domestic. Conversely, when the initiator adopts the domestic trusted data space standard and the target adopts the international data space standard, this method can also achieve authentication conversion from domestic to international through the same semantic library, mapping strategy library, and authentication strength level system. This bidirectional and peer-to-peer design enables this method to flexibly support various mutual recognition needs in cross-border and cross-domain data flow scenarios without deploying independent authentication gateways for different directions or writing one-way hard-coded conversion rules.

[0046] Therefore, this embodiment achieves bidirectional peer-to-peer authentication conversion between different data space standards by introducing a standard-independent intermediate semantic representation and a strength level comparison mechanism. Simultaneously, it mandates that the authentication strength after conversion is no lower than that before conversion, avoiding security degradation during cross-standard authentication. Based on a configurable semantic library and mapping strategy library, when the standard version evolves or new industry expansion requirements are added, only the entries in the library need to be updated without modifying the core authentication logic, thereby reducing maintenance costs and improving system scalability.

[0047] In this embodiment, the semantic library is used to establish the correspondence between different data space standards and intermediate semantic representations. For example, it converts authentication requests based on the International Data Space Standard (IDSA) into intermediate semantic representations, or converts authentication requests based on domestic trusted data space standards into intermediate semantic representations. To adapt to updates in data space standards, Specifically, the semantic library is constructed using a composite structure, which includes four components: a basic ontology model, a standard mapping table, an industry-specific extended vocabulary, and a version index.

[0048] The basic ontology model defines common semantics in the domain of data space authentication, including: identity subject, connector, trust anchor, authentication strength, permission type, validity period, usage restrictions, and transport certificate binding. This model is independent of any specific data space standard, providing a unified conceptual framework for authentication semantics across different standards.

[0049] The standard mapping table is used to maintain the mapping relationship between terms in the first data space standard and fields in the second data space standard. Mapping relationship types include equivalence mapping, inclusion mapping, mutual exclusion mapping, and conditional mapping. For example, an equivalence mapping can be established between the security configuration file field in the international data space standard and the authentication policy field in the domestic trusted data space standard.

[0050] The industry-specific extended thesaurus is used to adapt to the differentiated terminology of different industries. Industries such as government affairs, industry, and healthcare may have different terminology when describing concepts such as identity subjects and permission types. The industry-specific extended thesaurus records these differences and establishes a correspondence with the basic ontology model.

[0051] The version index is used to distinguish mapping definitions under different standard versions, different industry versions, and different deployment tenants. Each version record includes: standard identifier, standard version number, industry identifier, effective time, expiration time, compatibility range, and rollback version number. The version index supports the coexistence and traceable management of multiple versions of the semantic library.

[0052] Specifically, the semantic library can be a predefined static library or a dynamic incremental update mechanism introduced on top of a static core library. Specifically, the core security semantics are manually reviewed and then solidified and released. During operation, candidate mappings are generated based on new standard versions, industry terminology, and audit samples. After review, these are written into the corresponding version library to prevent unverified automatic learning results from directly affecting authentication security.

[0053] When executing an authentication request, during the actual authentication process, the corresponding version of the semantic library is selected based on the standard type, version field, connector industry, and target domain policy carried in the authentication request. If multiple candidate versions exist, the selection order is as follows: First, if the standard identifier and standard version number in the authentication request exactly match a version record in the semantic library, that version is selected; second, if no exact match exists, the version with the highest version number that matches the industry identifier carried in the authentication request is selected; finally, if none exists, a general version is selected as a fallback, with the industry identifier being a wildcard and the expiration time being empty. Simultaneously, the system supports a version rollback mechanism; when a new version mapping encounters compatibility issues, it can be restored to a previous stable version based on the rollback version number.

[0054] In this embodiment, the intermediate semantic representation is expressed using a structured JSON-LD object or an RDF triple set, or an equivalent internal structure, to ensure decoupling from any specific standard. In a preferred embodiment, the intermediate semantic representation is constructed using JSON-LD (JSON for Linking Data) format, serving as a structured authentication attribute set carrier independent of specific data space authentication standards. The entire JSON-LD object constitutes a complete intermediate semantic representation. The following is an example of a JSON-LD intermediate semantic representation: { "@context": "https: / / example.com / dataspace / auth / context", "subjectId": "did:example:connectorA", "credentialType": "DAT", "trustAnchor": "CN=IDS-Root-CA", "authnLevel": "L4", "privilegeSet": ["read", "write"], "audience": ["did:example:connectorB"], "validity": {"notBefore": "2026-04-21T10:00:00Z", "notAfter": "2026-04-21T11:00:00Z"}, "transportBinding": {"mtls": true, "certSha256": "ABCD1234"}, "nonceRelation": {}, "proofChain": ["x509-valid", "daps-jws-valid", "status-valid"] } The top-level fields in the above examples constitute the public field set described in this invention. Each field in this set can be used simultaneously to cover the authentication requirements of both international data space standards and domestic trusted data space standards.

[0055] subjectId (identity identifier): Adopts the decentralized identifier (DID) format, which is compatible with the domestic standard Unified Social Credit Code, device fingerprint and IDSA standard connector UUID, and uniformly expresses the identity of the subject.

[0056] credentialType: Marks the source credential type. Whether the original form is the IDSA standard Dynamic Attribute Token (DAT) or the domestic standard Challenge Response Token, it is mapped to a string value.

[0057] trustAnchor: Identifies the root certificate or authority required to verify credentials. It can be uniformly expressed as the IDS trust anchor in the IDSA standard (e.g., CN=IDS-Root-CA) or the national / industry root CA in the domestic standard.

[0058] authnLevel (Authentication Strength): Maps the authentication strength in different standards to the L1-L5 level system defined in this invention. For example, "L4" in the example can correspond to "mTLS+DAT" in the IDSA standard, or "certificate chain + challenge response + state verification" in the domestic standard, making authentication strengths across standards comparable.

[0059] privilegeSet (permission set): Declares the operation permissions requested by the initiator. It can be abstracted from the scope of DAT in the IDSA standard or the permission fields in the domestic standard business token.

[0060] audience: Specifies the intended recipient of the authentication request, used to correctly generate the target audience identifier required by the target standard during subsequent mapping.

[0061] Validity (expiration date): This includes the effective date (notBefore) and the expiration date (notAfter), and is a fundamental security attribute common to all certification standards.

[0062] transportBinding: Records the security binding method of the transport layer (such as mTLS) and the certificate hash value. It is the key information for verifying the security of transport binding when mapping across standards.

[0063] nonceRelation: In the IDSA standard scenario, it is an empty object (not involving bidirectional random number binding); in the domestic standard scenario, it is used to record the correspondence between the initiator's random number and the target's returned random number to ensure the challenge-response process is protected against replay attacks.

[0064] The proofchain records the results of each verification step (such as certificate chain verification, token signature verification, status verification, etc.) that the authentication credential has undergone in the form of an array, providing a basis for auditing and strength level determination.

[0065] The above fields together constitute an intermediate semantic representation independent of specific standards, enabling the authentication requirements of different data space standards to be uniformly expressed, compared, and mapped.

[0066] In the example above, the random number relationship field is an empty object under the current international data space standard scenario. When the first or second data space standard is a domestic trusted data space standard, the random number relationship field is used to record the correspondence between the initiator's random number and the target's random number, and its value is extracted from the challenge-response process, for example: "nonceRelation": { "sourceNonce": "381245", "targetNonce": "926411" } When the standard is the international data space standard, this field can be empty or missing. An empty field means the field exists but its value is an empty object (e.g., "nonceRelation": {}), indicating that the field is reserved in the semantic structure but currently has no valid data. A missing field means the field key-value pair does not appear at all in the intermediate semantic representation, indicating that the authentication process does not involve the concept of random number relationships. Both methods are acceptable, depending on the specific implementation requirements of the intermediate semantic representation. This design allows the same intermediate semantic representation structure to simultaneously carry different authentication semantics of international and domestic standards.

[0067] In this embodiment, the mapping strategy library can adopt a combination of one or more of the following storage formats: relational database tables, document-based configuration files, and rule engine knowledge bases. In one specific implementation, static field mappings are stored in configuration files, conditional judgment and level verification rules are stored in the rule engine, and audit and activation information is stored in relational database tables.

[0068] The mapping policy library supports hot updates. Once a policy is published, the running mapping engine detects its existence using the version number and verification digest. Upon detection, the mapping engine loads the new policy without restarting the service. For changes involving high-risk security policies, the system employs a double-buffering loading and canary implementation mechanism: the new policy is first loaded into a backup buffer, and after successful canary verification on a small number of requests, it is then switched to the main buffer to ensure uninterrupted authentication.

[0069] The mapping strategy library employs the following priority and conflict resolution rules: S31. When there is a strategy for a specific version of a standard and a general strategy for all versions of that standard, the precise version strategy shall be used first. S32. When there are strategies for specific industries and general strategies applicable to multiple industries, industry-specific strategies should be used first. S33. If one rule explicitly restricts a certain operation, while another rule allows the operation, the rule with the stronger restriction shall prevail. S34. If multiple rules are matched at the same time and there is a conflict, the result with higher security level, narrower permission scope and shorter validity period shall be selected. S35. If the conflict cannot be resolved according to the above rules, the mapping will be rejected and an alarm will be output.

[0070] To illustrate, if the permission level in the first standard is "read", it is mapped to "read-only" in the second standard; if it is "read / write", it is mapped to "read and write" in the second standard; if it is "read+download", and there is no permission combination in the second standard that can completely cover it, the mapping engine must not downgrade to "read-only" and should return the error code "mapping failed / manual confirmation required".

[0071] In this embodiment, the certification strength level system includes five levels from L1 to L5, and the definitions of each level are as follows: Level 1 represents single static credential verification, such as authentication using only a username and password or a static token.

[0072] Level 2 indicates single certificate chain verification, meaning that identity is confirmed solely through the digital certificate chain without involving other verification elements.

[0073] Level 3 stands for Certificate Chain Plus Challenge and Response Verification, which adds a challenge and response mechanism to the certificate chain verification and uses random number signatures to confirm the real-time validity of the certificate holder.

[0074] Level 4 indicates that the certificate chain plus dynamic token or two-factor authentication is used to complete the authentication, which is based on the certificate chain verification and combined with dynamic attribute tokens or two different types of verification factors.

[0075] Level 5 indicates that the certificate chain, dynamic token, subject state, usage constraints, and transport binding have all been verified, meaning that all five verification elements must be met simultaneously.

[0076] The source strength level is determined as follows: based on the authentication attribute set carried in the authentication request, the actual combination of verification elements used in the request is identified and matched with the definitions of L1 to L5 mentioned above to obtain the corresponding strength level. For example, when the authentication attribute set contains certificate chain verification information and dynamic attribute token information, but does not contain subject state verification information, it is determined to be level L4.

[0077] The target strength level is determined by estimating based on the authentication elements invoked by the authentication command. The authentication command explicitly specifies the authentication operations to be performed and the verification elements invoked. The system calculates the combinations of these elements and estimates the strength level that can be achieved after the command is executed, according to the definitions of L1 to L5.

[0078] Specifically, the following comparison procedure is performed: S41. Calculate the source strength level based on the authentication attribute set of the authentication request, and estimate the target strength level based on the authentication elements invoked by the authentication command. S42. Compare the target strength level with the source strength level. If the target strength level is greater than or equal to the source strength level, the authentication instruction can be executed, and the subsequent authentication process can begin. S43. If the target strength level is lower than the source strength level, a fallback mechanism is triggered, and the authentication command is not allowed to be executed directly.

[0079] To illustrate, when the source standard declares the authentication strength as L4 and requires that the certificate chain, token signature, and subject state are all valid, the target standard should at least meet the number of authentication elements corresponding to L4; if the target standard can only provide L3 capabilities, then this mapping is judged as a security level downgrade, the system suspends authentication and records the audit log.

[0080] In this embodiment, the rollback mechanism includes any one or more of the following operations: (1) Switch to a target policy that is more stringent than the current mapping policy. The system searches for an alternative policy with higher security requirements in the mapping policy library. If an alternative policy exists and can meet the source strength level requirements, the system uses the alternative policy to regenerate the authentication instructions.

[0081] (2) Add additional verification steps before executing the authentication command. The system adds additional verification operations on the basis of the original authentication command, such as adding subject status query and adding timestamp verification, in order to improve the target strength level to no less than the source strength level.

[0082] (3) The system requires the initiator to reapply for a higher-level credential before proceeding with the authentication. The system returns a prompt message to the initiator, requiring them to provide authentication credentials that meet the higher security level. The authentication process will be executed again after the initiator resubmits the credentials.

[0083] If none of the above fallback mechanisms can bring the target strength level up to the source strength level, the system will terminate the authentication and return a security level downgrade error code, while triggering an alarm.

[0084] In this embodiment, after executing the authentication command, the authentication result of the second data space standard is obtained. Subsequently, the system reuses the generated intermediate semantic representation and the context transaction identifier and proof chain information generated during the authentication process to reverse encapsulate the authentication result. Specifically, for fields in the second standard authentication result that are common to the first standard, the corresponding values ​​are preferentially read from the reused intermediate semantic representation; for newly added fields, they are converted into authentication result descriptions, session states, or subsequent call credentials recognizable by the first standard according to preset reverse mapping rules. This reverse mapping rule forms a reversible correspondence with the forward mapping rule in step S3. Finally, the system encapsulates the above information into a response message conforming to the first data space standard and returns it to the first standard connector, completing a complete two-way authentication closed loop.

[0085] In this embodiment, a unified exception handling mechanism is also configured: (1) If any concept in the authentication request cannot be matched in the semantic library, the authentication request is interrupted and a "semantic misalignment" error code is returned, along with the identifier of the unmatched concept.

[0086] (2) When the mapping policy library is unable to convert the intermediate semantic representation into an authentication request instruction, the authentication request is interrupted and a "policy incompatible" error code is returned.

[0087] (3) When the target strength level is lower than the source strength level and the fallback mechanism cannot be executed, the authentication request is interrupted and the "security level downgrade" error code is returned, and an alarm is triggered.

[0088] (4) When the certificate chain verification fails, the subject status verification fails, the dynamic attribute supply service metadata is unavailable, the dynamic attribute token signature is invalid, the random number relationship does not match, or the timestamp verification fails, the corresponding standardized error code is returned and written to the audit log.

[0089] The audit log records at least the semantic alignment results, rule hit records, security level determination criteria, target standard execution process, and error codes. This exception handling process makes authentication request failures no longer a black box; operations and maintenance personnel can directly locate missing concepts in the semantic library or conflicting rules in the policy library, forming a traceable and interpretable chain of evidence for authentication request decisions.

[0090] like Figure 2As shown, this embodiment of the present invention provides an authentication system supporting mutual recognition of multiple data space standards. The system includes a first standard connector, a second standard connector, a protocol conversion and semantic alignment layer, an authentication mapping and execution layer, a semantic library, a mapping policy library, and an audit log module. The system interacts with external Dynamic Attribute Provisioning Service (DAPS) and domestic entity status service.

[0091] The first standard connector and the second standard connector are examples of data space connectors conforming to the first and second data space standards, respectively. The first standard connector initiates an authentication request, and the second standard connector receives and responds to the converted authentication command.

[0092] The protocol conversion and semantic alignment layer is responsible for receiving authentication requests from the first standard connector, performing deep parsing of the requests based on a semantic library, extracting authentication attribute sets, and generating an intermediate semantic representation independent of specific standards. This layer is also responsible for reverse-encapsulating the authentication results returned by the authentication mapping and execution layer into a response conforming to the first data space standard, and returning it to the first standard connector. When the first or second data space standard is a domestic trusted data space standard, the protocol conversion and semantic alignment layer or the authentication mapping and execution layer queries the domestic subject status service for the subject identity status corresponding to the connector certificate to confirm the participant's validity.

[0093] The authentication mapping and execution layer is responsible for receiving the intermediate semantic representation generated by the protocol conversion and semantic alignment layer, converting it into authentication instructions conforming to the second data space standard based on the mapping policy library, and comparing the source strength with the target strength by invoking the authentication strength level system. Execution of the authentication instruction is only driven when the target strength is not lower than the source strength. This layer is also responsible for feeding back the authentication result obtained from the second data space standard to the protocol conversion and semantic alignment layer for reverse encapsulation. When the second data space standard is the international data space standard, the authentication mapping and execution layer obtains the issuer, token endpoint, and JSON Web Key Set Uniform Resource Identifier from the metadata endpoint of the Dynamic Attribute Provisioning Service (DAPS), and requests a dynamic attribute token from the token endpoint.

[0094] The semantic library stores the basic ontology model, standard mapping table, industry-specific extended lexicon, and version index, providing the basis for semantic parsing for protocol conversion and semantic alignment layers.

[0095] The mapping strategy library stores mapping rules between intermediate semantic representations and authentication instructions of different data space standards, providing conversion rule support for authentication mapping and the execution layer.

[0096] The audit log module is used to record semantic alignment results, rule hit records, security level determination criteria, target standard execution process, and error codes, providing data support for system operation and maintenance and compliance auditing.

[0097] In this embodiment, the data flow of the system is as follows: The first standard connector sends an authentication request to the protocol conversion and semantic alignment layer; when parsing the authentication request, the protocol conversion and semantic alignment layer sends a concept matching query to the semantic library, and the semantic library returns the corresponding mapping entry; when converting the intermediate semantic representation, the authentication mapping and execution layer sends a rule query to the mapping strategy library, and the mapping strategy library returns the applicable mapping rules; the authentication mapping and execution layer sends the authentication instruction generated by the conversion to the second standard connector and receives the authentication result returned by the second standard connector; during the authentication execution process, the authentication mapping and execution layer sends key events and judgment results to the audit log module for storage; after obtaining the authentication result fed back by the authentication mapping and execution layer, the protocol conversion and semantic alignment layer returns the response obtained by reverse encapsulation to the first standard connector.

[0098] When the authentication process involves international data space standards, the authentication mapping and execution layer interacts with the Dynamic Attribute Provisioning Service (DAPS) to obtain metadata and dynamic attribute tokens. When it involves domestic trusted data space standards, the protocol conversion and semantic alignment layer or the authentication mapping and execution layer interacts with the domestic subject status service to query the subject's identity status. The results of these external service calls are also recorded in the audit log module.

[0099] In this embodiment, it can be deployed in various architectural patterns. Specifically, the protocol conversion and semantic alignment layer, as well as the authentication request mapping and execution layer, can be deployed in any of the following ways: Same-machine side-vehicle mode: The protocol conversion and semantic alignment layer is deployed adjacent to the data space connector and runs on the same host or in the same process space as the connector. It is suitable for low-latency scenarios and can minimize cross-component communication overhead.

[0100] Same-domain gateway mode: A gateway instance provides standard mutual recognition capabilities for multiple connectors at the same time. Each connector communicates with the gateway through an internal network, which is suitable for medium-sized data spaces.

[0101] Centralized mutual recognition service mode: The central service uniformly maintains the semantic library, mapping policy library, audit logs, and DAPS / principal state connection configuration. Multiple authentication request gateways or connectors access the central service through remote calls, which is suitable for large-scale distributed deployment.

[0102] Furthermore, the authentication request mapping and execution layer can be deployed on the same machine as the target standard authentication request engine, or it can be deployed as a remote microservice. To avoid single points of failure, the semantic library, mapping strategy library, and auditing module are deployed in a master-slave or distributed manner, and DAPS metadata, jwks_uri, and domestic subject status results are cached for short periods to improve the authentication request response speed. Example 1

[0103] like Figure 3 As shown in the example, the initiator is connector A, which conforms to international data space standards, and the target is connector B, which conforms to domestic trusted data space standards. The authentication process is as follows: 1. After connector A establishes a bidirectional transport layer secure session with the authentication system, it sends a Hypertext Transfer Security Protocol (HTTP) request, with a dynamic attribute token in the request header. The dynamic attribute token includes declarations such as issuer, audience, validity period, scope, security profile, referencing connector, and transport certificate hash.

[0104] 2. The authentication system obtains the issuer, token endpoint, and JSONWeb key set Uniform Resource Identifier based on the metadata published by the dynamic attribute supply service; verifies the issuer, audience, validity period, scope, security profile, reference connector, and transport certificate hash of the dynamic attribute token; and extracts the identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, and transport binding information from the token and session as the authentication attribute set.

[0105] 3. Based on the above authentication attribute set, generate an intermediate semantic representation in JSON-LD format according to the preset public field set. Example of the JSON-LD intermediate semantic representation generated in this implementation example: { "@context": "https: / / example.com / dataspace / auth / context", "subjectId": "https: / / connectorA.example.com", "credentialType": "DAT", "trustAnchor": "IDS-Root-CA", "authnLevel": "L4", "privilegeSet": ["read", "write"], "resourceId": "urn:resource:dataset:001", "validity": { "notBefore": "2026-04-21T10:00:00Z", "notAfter": "2026-04-21T11:00:00Z" }, "transportBinding": { "mtls": true, "certSha256": "ABCD1234" }, "nonceRelation": {}, "proofChain": ["x509-valid", "daps-jws-valid", "dat-claims-valid"] } 4. The authentication mapping and execution layer converts the intermediate semantic representation into domestic standard authentication instructions, including: generating challenge interface call instructions (carrying verification parameters encrypted with the target party's public key, including the initiator's random number and certificate); generating response interface call instructions (carrying the signature result and encryption algorithm identifier such as SM4); generating instructions to generate derived symmetric encryption salt values ​​and obtain tokens; and attaching fields for expected permissions and security level requirements.

[0106] 5. After obtaining the certification result from domestic connector B, write back information such as signature validity, token validity period, and normal subject status to the intermediate semantic representation, and encapsulate it into an international data space standard response to return to connector A. Example 2

[0107] like Figure 4 As shown in the example, the initiator is connector C, which conforms to the domestic trusted data space standard, and the target is connector D, which conforms to the international data space standard.

[0108] 1. Connector C initiates a challenge-response process according to domestic standards. First, it sends a challenge interface request, carrying verification parameters (including the initiator's random number and certificate) encrypted with the target party's public key; then, it sends a response interface request, carrying the signature result and encryption algorithm identifier.

[0109] 2. The authentication system decrypts the verification parameters to obtain a random number and a certificate; performs certificate chain verification on the certificate; queries the subject's identity status service to confirm the subject's validity; verifies the correspondence between the signature and the random number; and extracts the identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, random number relationship, and proof chain information from the above process.

[0110] 3. Based on the above authentication attribute set, generate an intermediate semantic representation in JSON-LD format containing a random number relationship field according to a preset set of public fields. Example of JSON-LD containing a random number relationship field generated in this implementation example: { "@context": "https: / / example.com / dataspace / auth / context", "subjectId": "91310000MA000XXX1Y", "credentialType": "X509+Challenge", "trustAnchor": "CN-DataSpace-Root-CA", "authnLevel": "L4", "privilegeSet": ["read"], "resourceId": "urn:resource:dataset:009", "validity": { "notBefore": "2026-04-21T10:00:00Z", "notAfter": "2026-04-21T11:00:00Z" }, "transportBinding": {}, "nonceRelation": { "sourceNonce": "654321", "targetNonce": "112233" }, "proofChain": ["ca-valid", "subject-status-valid", "signature-valid", "nonce-bound"] } 4. The authentication mapping and execution layer converts the intermediate semantic representation into international standard authentication instructions, including: generating instructions to establish a bidirectional transport layer secure session (specifying the client certificate and trust store); generating instructions to request a dynamic attribute token from the dynamic attribute provisioning service (using the client credential authorization type and generating a client assertion); generating instructions to verify the returned dynamic attribute token (verifying the issuer, signature, validity period, audience, and transport binding); and generating instructions to attach the dynamic attribute token to the target connector request.

[0111] 5. After obtaining the token verification result returned by connector D, encapsulate the authentication success status, session allowance, and other information into a response that can be recognized by domestic standards (including mutual recognition success status, mapped session token, and timeout).

[0112] As demonstrated in the two examples above, regardless of whether the initiator adopts an international or domestic standard, the authentication system uses a unified intermediate semantic representation to carry the authentication attribute set, and then generates the corresponding authentication instructions based on the target standard. Conversely, the authentication result of the target standard is written back to the same intermediate semantic representation and restored to the response format of the source standard. This mechanism achieves a bidirectional reversible mapping between authentication semantics, authentication strength, permission boundaries, and response format, ensuring semantic fidelity and security consistency across standards.

[0113] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0114] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An authentication method supporting mutual recognition of multiple data space standards, characterized in that, Includes the following steps: Obtain the authentication request from the initiator that conforms to the first data space standard; Extract the authentication attribute set carried in the authentication request, and generate an intermediate semantic representation based on a preset semantic library and a preset set of public fields; wherein the set of public fields can cover the authentication description requirements of the first data space standard and the second data space standard; Based on a pre-built mapping strategy library, the intermediate semantic representation is converted into authentication instructions that conform to the second data space standard; Based on a preset authentication strength level system, the source strength level corresponding to the authentication request and the target strength level corresponding to the authentication instruction are determined, and the authentication instruction is executed only when the target strength level is not lower than the source strength level. After obtaining the authentication result of the second data space standard, a response conforming to the first data space standard is generated and returned to the initiator.

2. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, The semantic library is constructed from at least two of the following: a basic ontology model, a standard mapping table, an industry-specific extended lexicon, and a version index; wherein... The basic ontology model is used to define the common semantics of identity subjects, connectors, trust anchors, authentication strength, permission types, validity periods, usage restrictions, and transmission certificate bindings; The standard mapping table is used to maintain the equivalence, inclusion, mutual exclusion, or conditional mapping relationships between the terms of the first data space standard and the fields of the second data space standard. The industry-specific extended thesaurus is used to adapt to the differentiated terminology of different industries; The version index is used to distinguish the mapping definitions under different standard versions, different industry versions, and different deployment tenants. Each version record includes a standard identifier, standard version number, industry identifier, effective time, expiration time, compatibility range, and rollback version number.

3. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, Determining the source strength level corresponding to the authentication request includes: determining the source strength level based on the authentication attribute set carried in the authentication request; Determining the target strength level corresponding to the authentication instruction includes: estimating the target strength level based on the authentication elements invoked by the authentication instruction; The preset certification strength level system includes five levels from L1 to L5: Level L1 represents single static credential verification; Level 2 indicates single certificate chain verification; Level 3 indicates a certificate chain plus challenge-response verification; Level 4 indicates a certificate chain plus dynamic tokens or two-factor authentication; The L5 level indicates that the certificate chain, dynamic token, subject state, usage constraints, and transport bindings have all been verified.

4. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, The intermediate semantic representation is expressed using a structured JSON-LD object or an RDF triple set, and the authentication attribute set includes at least one of the following: identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, transmission binding information, random number relationship, and proof chain information; The random number relationship field is used to record the correspondence between the initiator's random number and the target's random number. When the first data space standard or the second data space standard is a domestic trusted data space standard, the value of the random number relationship field is extracted from the challenge response process. When the first data space standard or the second data space standard is an international data space standard, the random number relationship field is empty or missing.

5. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, The mapping strategy library supports hot updates, and the mapping engine loads the strategy without restarting the service after it is published. The mapping policy library adopts the following priority and conflict resolution rules: precise standard version policies take precedence over general policies, industry-specific policies take precedence over cross-industry policies, and explicit security restrictions take precedence over permission relaxation rules. If multiple rules are matched simultaneously and conflict, the result with higher security level, narrower permission scope, and shorter validity period will be selected. If the conflict still cannot be resolved, the mapping will be rejected and an alarm will be output. Furthermore, the authentication instruction is executed only when the target strength level is not lower than the source strength level; otherwise, a fallback mechanism is triggered. The fallback mechanism includes one or more of the following: switching to a target policy that is more stringent than the current mapping policy; Additional verification steps are added before executing the authentication instruction; The initiator is required to reapply for a higher-level certificate before proceeding with the authentication.

6. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, The generation of a response conforming to the first data space standard includes: The generated intermediate semantic representation, as well as the context transaction identifier and proof chain information generated during the authentication process, are reused. For fields in the authentication results of the second data space standard that already exist in the first data space standard, the corresponding values ​​are preferentially read from the reused intermediate semantic representation; For the newly added fields in the authentication results of the second data space standard, they are converted into authentication result descriptions, session states, or subsequent call credentials that can be recognized by the first data space standard according to the preset reverse mapping rules; wherein, the reverse mapping rules and the forward mapping rules in the mapping strategy library form a reversible correspondence. The read corresponding value, along with the converted authentication result description, session status, or subsequent call credentials, are encapsulated into a response message conforming to the first data space standard.

7. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, When the first data space standard is the international data space standard, the authentication request is a Hypertext Transfer Security Protocol request established on a bidirectional transport layer security session, and the authentication request carries a dynamic attribute token. The set of authentication attributes carried in the authentication request includes: The issuer, token endpoint, and JSON Web Key Set Uniform Resource Identifier are determined based on the server metadata published by the dynamic attribute provisioning service; the issuer, audience, expiration time, effective time, scope, security profile, reference connector, and transport certificate secure hash algorithm 256 declaration of the dynamic attribute token are verified; the identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, and transport binding information are extracted from the dynamic attribute token and the bidirectional transport layer secure session as the authentication attribute set; or... When the first data space standard is a domestic trusted data space standard, the authentication request is a challenge-response interface request. The authentication request carries verification parameters encrypted with the target party's public key. The verification parameters include at least the initiator's random number and the initiator's certificate. The set of authentication attributes carried in the authentication request includes: The verification parameters are decrypted to obtain the initiator's random number and initiator's certificate; the initiator's certificate is subjected to certificate chain verification; the subject identity status service is queried to obtain the subject identity status corresponding to the initiator's certificate; the signature result returned by the initiator is received, and the correspondence between the signature result and the initiator's random number is verified; the identity identifier, credential type, trust anchor, authentication strength, permission information, validity period, random number relationship, and proof chain information are extracted from the encrypted relationship between the initiator's certificate, the certificate chain verification result, the subject identity status, the signature result, and the subsequently returned token as the authentication attribute set.

8. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, When the second data space standard is an international data space standard, the step of converting the intermediate semantic representation into an authentication instruction conforming to the second data space standard includes: Generate instructions to establish a bidirectional transport layer secure session, specifying the client certificate and trust store; generate instructions to request a dynamic attribute token from the token endpoint of the dynamic attribute provisioning service, wherein the request method is a client credential authorization type, and generate a client assertion; generate instructions to verify the returned dynamic attribute token, the verification including verifying the issuer and metadata consistency, verifying the signature, verifying the validity period and audience, and verifying the binding of the transport certificate secure hash algorithm 256 with the bidirectional transport layer secure session certificate; generate instructions to append the dynamic attribute token to the target connector request; or, When the second data space standard is a domestic trusted data space standard, the step of converting the intermediate semantic representation into an authentication instruction conforming to the second data space standard includes: Generate a challenge interface call instruction, which carries verification parameters encrypted with the target party's public key, the verification parameters including the initiator's random number and initiator's certificate extracted from the intermediate semantic representation; generate a response interface call instruction, which carries a signature result and encryption algorithm identifier; generate an instruction to derive a symmetric encryption salt and obtain a token; The authentication instruction includes fields for desired permissions and security level requirements.

9. The authentication method supporting mutual recognition of multiple data space standards according to claim 1, characterized in that, It also includes exception handling procedures: When no concept in the authentication request can be matched in the semantic library, the authentication is interrupted and a semantic misalignment error code is returned, along with the identifier of the unmatched concept. When the mapping policy library is unable to convert the intermediate semantic representation into the authentication instruction, the authentication is interrupted and a policy incompatibility error code is returned. When the target strength level is lower than the source strength level and the fallback mechanism cannot be executed, authentication is interrupted and a security level downgrade error code is returned, and an alarm is triggered. When certificate chain verification fails, subject status verification fails, dynamic attribute provisioning service metadata is unavailable, dynamic attribute token signature is invalid, random number relationship does not match, or timestamp verification fails, the corresponding standardized error code is returned and written to the audit log. The audit log shall at least record the semantic alignment results, rule hit records, security level determination basis, target standard execution process, and error codes.

10. A two-way authentication system supporting mutual recognition between different data space standards, characterized in that, include: The protocol conversion and semantic alignment layer is used to obtain authentication requests from the initiator that conform to the first data space standard; In addition, it is used to extract the authentication attribute set carried in the authentication request and generate an intermediate semantic representation based on a preset semantic library and a preset set of public fields; wherein the set of public fields can cover the authentication description requirements of the first data space standard and the second data space standard. The authentication mapping and execution layer is used to convert the intermediate semantic representation into an authentication instruction conforming to the second data space standard based on a preset mapping strategy library; to determine the source strength level corresponding to the authentication request and the target strength level corresponding to the authentication instruction according to a preset authentication strength level system, and to execute the authentication instruction only when the target strength level is not lower than the source strength level; and to generate a response conforming to the first data space standard after obtaining the authentication result of the second data space standard, and return it to the initiator.

Images