Decentralized identity authentication method and system for light and simple architecture

Abstract

The invention relates to a decentralized identity authentication method and system of a light and simple framework, and the method comprises the steps: generating a public and private key pair locally, constructing a DID identifier, assembling a DID document, and uploading the DID document to a decentralized storage; oIDC authentication or payment signature KYC authentication with a third-party platform specified by a user is carried out, and Web2 authentication information is returned to realize DID binding; and based on the Web2 authentication information, verification is carried out through a local zero-knowledge proof circuit, and the DID identifier and a document address are bound and linked to realize identity authentication. Compared with the prior art, the method has the advantages of reduced deployment cost and threshold, identity migration from Web2 to Web3, strong anti-Sybil attack ability, full stack decentralization, strong standard compatibility and ecological interoperability, good privacy protection depth and flexibility and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed digital identity management, in particular to a light and simple architecture decentralized identity authentication method and system. BACKGROUND

[0002] Digital identity is the core identity and trust basis of Internet users. In the Web2 era, it presents the characteristics of centralization and fragmentation. User identity information is stored in various platforms in a scattered manner, and there is no ownership, control and migration right. There are three major drawbacks of data monopoly, poor cross-platform interoperability, privacy leakage and single point failure. To solve this problem, W3C released the decentralized identifier (DID) v1.0 specification, which proposes a new paradigm of user self-generated identifier, identity controlled by public and private keys, decentralized storage of documents and support for verifiable credentials, and is regarded as the infrastructure of Web3 identity layer.

[0003] Although the DID theory continues to improve and many technical solutions emerge, it has not been widely used for six years. The core reason is that it is trapped in multiple dilemmas: in terms of technology, the existing solutions are mostly "heavy infrastructure" architecture, which has high deployment and operation costs and high barriers to entry, excluding small and medium-sized developers; in terms of network effect, it is trapped in the "application-user" cold start dilemma and lacks effective incentive mechanism; in terms of benefit cost, the development cost of Web3 projects integrating DID is high and the benefit is difficult to quantify, so the priority is low; in terms of power structure, the path dependence and lock-in effect of Web2 giant account system are significant, and the conversion cost of existing solutions is high and the immediate value is insufficient; in terms of technical implementation, the credibility and incentive of the issuing agency have not been solved, and the privacy protection technology is difficult to engineer and the on-chain verification cost is high; in terms of user education, the complex concept leads to a cognitive gap and popularization is hindered.

[0004] Therefore, at the present stage when the DID ecology is not mature, how to realize the light and simple architecture decentralized authentication is the key to breaking the deadlock. SUMMARY

[0005] The purpose of the present application is to overcome the defects of the prior art and provide a light and simple architecture decentralized identity authentication method and system to solve or partially solve the problems that the existing method needs to build a special identity service node, relies on a traditional issuing agency or audit committee, and does not have the ability to resist the attack of a witch.

[0006] The purpose of the present application can be achieved by the following technical solutions: In one aspect of the present application, a light and simple architecture decentralized identity authentication method is provided, comprising the following steps: Generating a public-private key pair locally and constructing a DID identifier, assembling a DID document and uploading it to a decentralized storage; Binding DID by returning Web2 authentication information through OIDC (OpenID Connect) authentication or payment signature KYC authentication with a user-specified third-party platform; Based on the Web2 authentication information, the DID identifier is bound to the document address and chained by verifying through a local zero-knowledge proof circuit, realizing identity authentication.

[0007] As a preferred technical solution, the process of OIDC authentication includes the following steps: Embed the DID identifier in the nonce field to build an OIDC authorization request adapted to the third-party platform; After the user completes the login authorization on the third-party platform, the Web2 authentication information returned by the third-party platform is obtained; Based on the ID Token in the Web2 authentication information, kid analysis, public key acquisition and signature verification are performed to complete DID binding.

[0008] As a preferred technical solution, under the premise of using OIDC authentication, the process of verifying through a local zero-knowledge proof circuit includes the following steps: Take the ID Token in the Web2 authentication information as a private input, and take the DID identifier, nonce field hash and current block height as inputs to perform Token signature verification, payload verification, Token metadata verification and nonce binding verification. In response to all verifications passing, the user field in the Web2 authentication information is encrypted, combined with the DID identifier to output a commitment for on-chain verification.

[0009] As a preferred technical solution, under the premise of using OIDC authentication, the process of binding the DID identifier to the document address and chaining includes the following steps: Based on the commitment output by the zero-knowledge proof circuit, build and sign a transaction request; After the user confirms, the signed transaction request is submitted to the transaction network, and after verification and inspection, the DID identifier and the document address are bound and chained.

[0010] As a preferred technical solution, under the premise of using OIDC authentication, it also includes the following DID login process: Send the DID identifier and transaction network ID to the third-party Web3 platform to be logged in. After the third-party Web3 platform calls the corresponding transaction network to query the corresponding DID state and document address, obtains the DID document from the decentralized storage and extracts the public key for verification, DID login is realized.

[0011] As a preferred technical solution, the process of payment signature KYC authentication includes the following steps: After the user configures the information of the third-party platform, the DID identifier is embedded into the attach field, a request is constructed and sent to the ordering interface of the third-party platform; The prepayment transaction session identifier returned by the third-party platform is obtained, the user completes the transaction, the callback notification is obtained, and after signature matching verification, the Web2 authentication information is obtained.

[0012] As a preferred technical solution, under the premise of adopting payment signature KYC authentication, the verification process through the local zero-knowledge proof circuit includes the following steps: The callback notification in the Web2 authentication information is taken as a private input, the DID identifier, the hash of the attach field and the merchant number are taken as public inputs, and through XML parsing, merchant number matching verification, payment state verification, attach field verification and signature verification, the merchant number in the Web2 authentication information is encrypted in response to all verification passing, and the DID identifier is combined to output a commitment for on-chain verification.

[0013] As a preferred technical solution, under the premise of adopting payment signature KYC authentication, the process of binding the DID identifier and the document address on-chain includes the following steps: After completing the commitment of zero-knowledge proof on the chain, write into the DID record; Return the funds of the transaction.

[0014] As a preferred technical solution, it also includes the process of obtaining verifiable credentials based on TLSNotary oracle: Select the data source platform and the target of requesting proof, and initiate an asset proof request; Establish communication with the data source platform and the TLSNotary oracle node, and obtain a handshake proof through three-party notarization; Log in to the data source platform, construct a client request and send it to the data source platform; Receive the encrypted message from the data source platform, extract the TLS record layer ciphertext, nonce field, GCM mode authentication tag and response sequence number, package and send to the TLSNotary oracle node; The TLSNotary oracle node verifies the handshake proof and decrypts it to generate a TLSNotary notarization receipt; Send the TLSNotary notarization receipt to the issuer platform, and construct a W3C credential; The issuer platform calculates the hash of the W3C credential and updates the on-chain DID record; Realize on-chain verification.

[0015] In another aspect of the present application, a light and simple decentralized identity authentication system is provided for implementing the foregoing decentralized identity authentication method, and the system comprises: A user terminal autonomous module for locally generating a public-private key pair and constructing a DID identifier, assembling a DID document and uploading to a decentralized storage; A Web2 authentication adaptation module for returning Web2 authentication information to realize DID binding by performing OIDC authentication or payment signature KYC authentication with a user-specified third-party platform; A zero-knowledge proof module for verifying based on the Web2 authentication information through a local zero-knowledge proof circuit; An on-chain registration module for binding the DID identifier and the document address on-chain to realize identity authentication; A verification query module for realizing DID document parsing and credential retrieval, as well as cryptographic verification and attribute extraction; A credential management module for realizing TLSNotary oracle handshake and W3 credential format packaging to realize EAS on-chain evidence.

[0016] Compared with the prior art, the present application has at least one of the following beneficial effects: (1) Solving the Web3 identity cold start problem: the present application returns Web2 authentication information to realize DID binding by performing OIDC authentication or payment signature KYC authentication with a user-specified third-party platform, reuses the existing Web2 accounts of billions of users, and the user acquisition cost is low, the user does not need to understand the concepts of mnemonic, gas fee, etc., and only needs to log in to the third-party platform or complete a payment to have a DID, which has no difference from Web2 experience, and is helpful to realize the popularization of DID mode.

[0017] (2) Realizing the minimum viable product of decentralized trust: the traditional DID system pursues perfect complete decentralization, but ignores the gradualness of engineering implementation, the present application ingeniously converts the current stage Web2 platform as a trust anchor into part of the DID system, so that the landing of DID changes from impossible to possible.

[0018] (3) Releasing the value of Web2 data: the user has deposited a large amount of trusted data in the payment platform, and the present application can realize the portability of data under the premise of protecting privacy by carrying these data into Web3 through the TLSNotary technology.

[0019] (4) Establish a compliance bridge for Web3 applications: DeFi, DAO, and other applications are facing increasing regulatory pressure, KYC is a necessity, and the centralized mode of traditional KYC service providers is contrary to the ethos of Web3. The payment signature KYC channel provides a semi-decentralized compliance path, with data coming from regulated payment platforms, but the verification process is performed by a smart contract, with no intermediaries, meeting regulatory requirements while preserving the decentralized spirit.

[0020] (5) Promote the practicality of zero-knowledge proof technology: This invention brings zero-knowledge proof from the cryptography laboratory to daily applications, and users unknowingly use ZK technology to protect privacy. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 Schematic diagram of decentralized identity authentication of the light and simple architecture in the embodiment; Figure 2 DID registration flowchart in the embodiment; Figure 3 Verifiable credential generation and verification flowchart in the embodiment. DETAILED DESCRIPTION

[0022] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the present application.

[0023] Embodiment 1 To solve the problems of the prior art, the embodiment provides a light and simple architecture decentralized identity authentication system. Through architecture innovation, mechanism design, and engineering optimization, the light and simple architecture decentralized identity authentication system realizes lightweight deployment and rapid cold start of the decentralized identity system, reduces the integrated cost by two orders of magnitude on the premise of maintaining cryptographic security and standard compatibility, and provides a key technical bridge and practical paradigm for DID to move from theory to large-scale application.

[0024] The purpose of this embodiment is to completely overcome a series of core obstacles hindering the large-scale deployment of existing decentralized identity systems, such as high deployment costs, high operational barriers, lack of network effects, and unclear explicit benefits. It aims to provide a truly lightweight, simple, and rapidly deployable decentralized identity system with a complete functional closed loop, along with its deployment method. The technical vision of this embodiment is to achieve plug-and-play functionality for the DID system, enabling any individual or team with basic blockchain development capabilities to complete system integration within hours, bringing deployment costs close to zero, while ensuring the system meets production-grade requirements in terms of security, privacy, attack resistance, and standards compatibility.

[0025] The core technology of this embodiment lies in not establishing any infrastructure dedicated to DID, but rather creatively combining and cryptographically enhancing the Web2 identity services and Web3 blockchain infrastructure that are prevalent in the existing internet ecosystem, thereby constructing a trust migration channel from traditional identity to decentralized identity. This approach overturns the traditional approach of building a DID system from scratch, instead adopting an integration strategy, transforming the existing identity infrastructure of third-party platforms into trust anchors for the DID system, provided that authorization is obtained.

[0026] To achieve the above objectives, this embodiment innovates in four aspects: architecture design, authentication mechanism, credential model, and deployment paradigm. I. Serverless Web2 authentication channel architecture.

[0027] Two fully decentralized Web2 identity authentication channels that do not require the operator to maintain servers are proposed, fundamentally solving the problem that traditional DID systems need to build their own highly available authentication services.

[0028] 1. OIDC Self-Authentication Channel: The core insight of this channel lies in the fact that the OIDC (OpenID Connect) protocol itself provides a complete identity authentication and signature mechanism. Traditional solutions require a self-built proxy server to translate OIDC responses into on-chain transactions. This embodiment, however, uses zero-knowledge proof technology to allow users to complete verification and proof generation locally and submit it directly to the blockchain, eliminating the need for an intermediate server. Specifically: Request construction autonomy: The user client has a built-in OAuth 2.0 protocol stack, enabling it to construct a compliant authorization request URL and embed the hash value of the DID identifier into the nonce parameter. This design leverages the nonce's anti-replay attack properties and extends it as a DID declaration carrier.

[0029] Localized signature verification: After obtaining the ID Token, the user completes the JWT signature verification within the client. The client has a built-in cache of the OIDC service provider's JWK (JSON Web Key) or supports dynamic retrieval, and verifies the validity of the RS256 or ES256 signature through a standard cryptographic library to ensure that the token has not been tampered with.

[0030] Zero-knowledge proof privacy protection: Crucially, users don't need to submit their IDTokens containing sensitive information (like email addresses and names) in plaintext on the blockchain; instead, they submit a zero-knowledge proof. The circuit logic for this proof includes: verifying the validity of the token signature, extracting the nonce field, and proving that the hash of the nonce equals the publicly input DID hash. The circuit cryptographically binds the user's unique identifier (sub field) to the DID through a Pedersen commitment. This commitment value is the circuit's public output, but the original sub value cannot be deduced, achieving a strong privacy guarantee: "I know that a token signed by a third-party platform contains my DID claim, but I won't tell you my email address."

[0031] 2. Payment signature KYC channel: This channel transforms the payment function into an identity authentication method. Its technical principle is as follows: Legal validity of payment signatures: In the callback notification, the payment platform's payment interface uses the platform's private key to sign key order parameters (including amount, merchant ID, order number, and the attach field). This signature is legally considered the platform's confirmation of the transaction and is non-repudiable. In this embodiment, with authorization from the payment platform, the DID identifier is placed in the attach field, and the payment platform digitally signs the user's DID declaration.

[0032] The economic design to prevent Sybil attacks: Payment channels inherently possess strong real-name authentication features, with each payment account linked to a bank card, ID card, and mobile phone number. If an attacker attempts to create fake identities in bulk, they would need to register payment accounts and complete real-name authentication in batches, which is economically impractical. Even if an attacker were willing to pay small amounts, frequent payment activity would trigger the payment platform's risk control system.

[0033] II. Standardized credential model based on EAS and InterPlanetary File System (IPFS).

[0034] This embodiment abandons the traditional approach of requiring self-built credential storage and indexing services in the credential management layer, and reuses Web3 public infrastructure.

[0035] 1. Advantages of EAS On-Chain Pegs. The Ethereum Attestation Service (EAS) is a permissionless, free-to-use on-chain proof registry. This embodiment uses EAS as the root of trust for credentials, rather than storing the complete credential content. This design brings multiple benefits.

[0036] Cost optimization: By storing only the 32-byte hash value of the credential on-chain, gas consumption is reduced from hundreds of thousands of units to less than 50,000 units, a reduction of an order of magnitude in cost.

[0037] Privacy is flexible: The complete credential content is stored in IPFS or off-chain, and users can achieve fine-grained privacy protection through access control, such as using DID authentication encryption, to avoid exposing all attributes on the chain.

[0038] Interoperability: EAS supports custom schemas. This embodiment pre-registers a schema that conforms to the W3C VC standard. Any project using the same schema can parse the credentials of this system, achieving cross-project mutual recognition.

[0039] 2. Enhanced Trust in the TLSNotary Oracle. Traditional oracles like Chainlink require nodes to stake tokens to economically guarantee data authenticity. However, the Web2 data processed in this embodiment, such as bank balances and social media account status, is difficult to verify through economic models. TLSNotary guarantees authenticity through cryptographic means rather than economic incentives: Session key isolation: The TLSNotary node only records handshake parameters and does not possess the session key, thus preventing the decryption of user data and fundamentally eliminating the risk of data leakage.

[0040] Zero-knowledge proof optional: Users can selectively prove to the verifier that a certain field in the response meets the condition without revealing the specific age, which is achieved through a zero-knowledge range proof circuit.

[0041] Non-repudiation: Once TLSNotary is issued, users cannot deny the data they obtained from the Web2 service, and this proof can be used permanently for future credential verification.

[0042] III. Modular decoupling and plug-and-play deployment paradigm.

[0043] The system architecture design in this embodiment follows a strict modular principle, with modules communicating through clearly defined interfaces and no implicit dependencies. This design provides deployment flexibility.

[0044] Minimize integration costs: If a DeFi project only needs KYC functionality, it can integrate only the client module, the payment signature KYC sub-module, and the on-chain registration contract, ignoring the credential management module. The development workload can be controlled within 2 person-days.

[0045] Progressive enhancement: In the early stages of the project, simple OIDC self-authentication can be used. As the business develops, payment KYC channels and TLSNotary credentials can be gradually integrated, resulting in a smooth system evolution.

[0046] Multi-chain compatibility: The on-chain registration module is written in Solidity and can be deployed on any EVM-compatible chain; at the same time, its design logic can be migrated to non-EVM ecosystems such as Polkadot and Cosmos, simply by replacing the cryptographic primitives.

[0047] See Figure 1 This document outlines the data flow and dependencies among the six major components of this system: the user-side module, the Web2 authentication adaptation module, the zero-knowledge proof layer, the on-chain registration module, the credential management module, and the verification and query module. The user-side module, acting as the initiator, interacts with the zero-knowledge proof layer through the dual-channel authentication module, ultimately achieving a complete closed loop for on-chain identity registration and credential lifecycle. The following sections will describe the internal structure, interface definitions, and collaborative mechanisms of each module in this simplified decentralized identity system, providing an architectural foundation for the specific processes in subsequent embodiments. (1) User-side autonomous module.

[0048] The client module is the only entry point to the system. Its design follows the principle that data sovereignty resides with the user. All cryptographic operations are performed locally, and sensitive information does not leave the user's device.

[0049] Key Management Submodule: Employs a hierarchical deterministic wallet (HD Wallet) architecture. The master seed is generated from a 128-bit truly random number and converted into a mnemonic phrase using the BIP-39 standard for user backup. An identity master key (path m / 44' / 60' / 0' / 0 / 0) is derived from the master seed, followed by a signing key pair (m / 44' / 60' / 0' / 0 / 0 / 1) and an encryption key pair (m / 44' / 60' / 0' / 0 / 0 / 2), thus separating key usage. The private key is stored in a secure area on the device (iOS Keychain or Android Keystore), requiring biometric authorization for access.

[0050] DID identifier construction logic: To prevent DID collisions and enhance readability, the identifier adopts the following structure: did:{method}:{chain-id}:{username}-{timestamp-sha256}, where method is "oidc" or "payment", chain-id is the chain identifier (such as eth, polygon), username is a user-defined string, and timestamp-sha256 is a hash suffix of timestamp and random number, ensuring global uniqueness. For example: did:oidc:eth:alice-0x3a7b9c2d.

[0051] DID Document Assembly Engine: This engine incorporates the W3C DID specification's JSON-LD context template, automatically converting user public keys to JsonWebKey2020 format and generating a verificationMethod array. For each public key, it generates corresponding authentication and assertionMethod references. The service array contains at least two service endpoints: one of type LinkedVerifiableCredential, pointing to the EAS query address; and another of type DIDLinkedResource, pointing to the complete document stored in IPFS. The engine also supports user-defined extended services (such as social media links) to improve DID interoperability.

[0052] Document Upload and Version Management: When DID documents are uploaded to IPFS, they are packaged in CAR (Content Addressable Array) format, supporting sharding and incremental updates. Each document update generates a new IPFS hash, but the DID identifier remains unchanged; only the documentUrl recorded on the chain changes, ensuring DID updability. The client maintains the document version history and supports rollback to previous versions.

[0053] (2) Web2 authentication adaptation module.

[0054] This module is key to the system's lightweight and simple features, shielding the interface differences between different Web2 services through a standardized adapter pattern.

[0055] See Figure 2The flowchart for DID registration details the specific execution steps and decision branches of two Web2 authentication channels. The left path shows the self-authentication process based on the OIDC protocol, from key generation, DID construction, authentication request construction, ID token acquisition to zero-knowledge proof generation and on-chain registration. The right path shows the KYC authentication process based on payment signatures, highlighting the embedding of the DID identifier in the attach field and payment signature capture. The two paths converge at the on-chain registration stage, demonstrating the flexibility and inclusiveness of the system design.

[0056] 1) OIDC Self-Authentication Submodule Architecture: This submodule does not rely on any centralized backend and is entirely implemented using client-side JavaScript / native code. Internally, it contains an OAuth 2.0 state machine to manage the various states of the authorization code process. Core components include: 1. Authorization request builder: Based on the OIDC service provider selected by the user, automatically fill in the authorization endpoint, client ID (using the application credentials registered by the user), redirect URI (using the urn:ietf:wg:oauth:2.0:oob mode to avoid building a self-built callback server), scope (fixed to openid email profile) and nonce (embedded DID hash).

[0057] 2. Enhanced security with PKCE: Automatically generates code_verifier (128-byte random number) and code_challenge (Base64Url encoding of SHA256(code_verifier)) to prevent authorization code interception attacks.

[0058] 3. ID Token Parser: After obtaining the token, it splits the JWT into three parts: header, payload, and signature. It extracts the kid field from the header, dynamically downloads the service provider's JWK Set, and verifies the signature using RSA-PSS or ECDSA algorithms. Upon successful verification, it extracts fields such as nonce, sub, and iss for subsequent use in the ZooKeeper circuit.

[0059] 2) Payment Signature KYC Submodule Architecture: This submodule encapsulates the calling details of the payment platform V3 API and Alipay Open API, providing a unified payAndAuthenticate interface. The internal workflow is as follows: 1. Merchant Parameter Configuration: Users configure their payment platform's appid, mchid, and APIv3 key in the client application. To protect key security, fragmented keys or proxy re-encryption technology can be used to ensure that the key is not exposed in the front-end code.

[0060] 2. Unified Order Request Construction: Construct an order request conforming to the payment platform's XML or JSON format, and fill in the DID identifier in the attach field (length limited to 128 bytes, must be Base64 encoded and compressed). Set total_fee to the smallest currency unit (e.g., 1 cent), and fill in descriptive text such as "Identity Verification" in the body field.

[0061] 3. Payment Result Monitoring: Payment results are obtained using a polling query or asynchronous notification mechanism. Payment V3 callback notifications include `sign_type` and `sign` fields. The `sign` value is the result of HMAC-SHA256 calculation performed by concatenating all parameters in the callback body in lexicographical order with the merchant key. The submodule automatically performs signature verification to ensure that the notification originates from the official source.

[0062] (3) Zero-knowledge proof module.

[0063] The zero-knowledge proof module is the core of privacy protection in this system. Its design aims to achieve fast proof generation speed, low verification cost, and auditable circuit logic.

[0064] Circuit architecture design: A layered circuit design is adopted, separating common logic (such as hash calculation and signature verification) from path-specific logic. The common layer includes SHA-256, Keccak-256, and Poseidon hash function circuits, which have been deeply optimized to minimize the number of constraints. OIDC path-specific circuits include JWT parsing, JWK verification, and RSA / ECDSA signature verification; payment path-specific circuits include HMAC-SHA256 and signature certificate chain verification.

[0065] Proof System Selection: The client-side proof generation adopts the Groth16 scheme due to its fixed proof size (only 3 group elements) and fast verification speed. Although Groth16 requires a trusted setup, the circuit logic of this invention is fixed. A multi-party computation (MPC) ceremony can be jointly performed by the community at project startup to generate and publicly disclose the verification and proof keys. All users can then reuse the same set of keys, avoiding duplicate trusted setups. For scenarios requiring higher transparency, alternatives such as PLONK or Halo2, which do not require a trusted setup, can be used.

[0066] Proof generation performance optimization: Client-side proof generation is a key bottleneck for user experience. This invention employs several optimization strategies: First, batch proof technology, which merges multiple statements to be proven into a single circuit instance, amortizing the proof generation overhead; second, hardware acceleration, utilizing WebAssembly SIMD instructions or GPUs to accelerate elliptic curve operations; and third, pre-computation and caching, pre-computing and caching the common input parts of the circuit to reduce redundant computations. Real-world testing shows that on mainstream smartphones, the proof generation time can be controlled within 3-5 seconds, which is within an acceptable range for users.

[0067] On-chain verification cost: Groth16's on-chain verification requires only 3 elliptic curve pairing operations, consuming approximately 200,000 gas units on the Ethereum mainnet, and less than $0.01 on L2 platforms like Polygon. The verification contract uses the EIP-196 pre-compiled contract for pairing operations and EIP-197 for verifying the pairing results, ensuring optimal verification efficiency.

[0068] (4) On-chain registration module.

[0069] The DID registration smart contract adopts a simple design, retaining only the core functions, reducing audit complexity and deployment costs.

[0070] 1) State Structure Design: The contract maintains a mapping from DID identifiers to DIDRecord structures. DIDRecord contains: 1. `documentUrl`: The IPFS hash of the DID document, stored as a 32-byte string containing the SHA-256 hash of the CID; 2. `authType`: An enumeration of authentication types, where 0 represents OIDC, 1 represents payment signature, 2 represents multi-signature, and other extended types; 3. `authHash`: The hash anchor for Web2 authentication, either an ID token hash or a payment signature hash, used for ZK circuit verification; 4. `createdAt`: A block timestamp recording the registration time; 5. `isActive`: A boolean value supporting the revocation and restoration of the DID.

[0071] 2) Implementation of core functions: 1. The `registerDID` function: Receives the DID string, `documentUrl`, `authType`, `authHash`, and `zkProof`. It calls the verifier contract to verify the validity of the proof. If the verification passes, it writes the proof to the state map and triggers the `DIDRegistered` event. To prevent DID snatching, the function requires that the address hash of `msg.sender` must match the username portion of the DID identifier, or ownership must be proven through a specific challenge-response mechanism.

[0072] 2. The updateDocument function: Allows the DID owner to update the documentUrl. It requires submitting the signature of the old document and the hash of the new document to ensure that the update operation is authorized.

[0073] 3. RevokeDID function: Allows the owner or a specific governance contract to set isActive to false, enabling voluntary revocation or violation banning of DID.

[0074] 3) Anti-replay and anti-squatting mechanisms: Each DID registration transaction includes a range constraint of the current block height (e.g., it must be valid within the first 10 blocks) to prevent proofs from being replayed. Simultaneously, the contract maintains a set of used authHash values ​​to ensure that only one DID can be registered for the same Web2 authentication, preventing Sybil attacks.

[0075] (5) Voucher Management Module.

[0076] The credential management module implements a complete closed loop from Web2 data sources to on-chain verifiable credentials.

[0077] Detailed process of the TLSNotary three-party protocol: 1. Handshake Capture Phase: When the user client and the Web2 service begin the TLS handshake, the TLSNotary node captures the ClientHello and ServerHello messages using network packet capture tools such as libpcap, extracting the public key parameters from the client_random, server_random, and key_share extensions. This process requires no man-in-the-middle attack and is entirely passively monitored, therefore the Web2 service is unaware of it.

[0078] 2. Key Commitment Phase: After the handshake is complete, the user client calculates the pre-master secret based on the ECDHE algorithm, and then derives the session key. The client calculates the commitment value of the session key (e.g., SHA256(session_key|| client_random)) and submits it to TLSNotary. TLSNotary records this commitment but does not possess the session key itself.

[0079] 3. Communication Encryption Phase: Users use their session key to communicate with the Web2 service, sending requests and receiving responses. All application data is encrypted and protected.

[0080] 4. Notarization Request Phase: The user packages the received encrypted application data (including the initialization vector, sequence number, and ciphertext) and submits it along with the handshake parameters to TLSNotary. TLSNotary uses the recorded handshake parameters to reconstruct the intermediate values ​​in the key derivation process, verifies whether the user's submitted commitment value matches, and if they match, proves that the user does indeed possess the correct session key. It then decrypts the encrypted data submitted by the user and verifies that its content is consistent with the response format of the Web2 service.

[0081] 5. Notarization Certificate Generation: TLSNotary generates a JSON-formatted certificate containing the following elements: `session_key_proof`: Proof of the validity of the session key; `response_commitment`: A hash commitment to the response content; `notary_signature`: The signature of the proof by the TLSNotary node using its long-term private key; `timestamp`: A notarized timestamp; `merkle_root`: If the response content is large, a Merkle root can be calculated. Partial disclosure is supported.

[0082] W3C credential encapsulation logic: After receiving the TLSNotary certificate, the issuer parses the certificate and extracts user attributes in a Trusted Execution Environment (TEE). The credential JSON-LD structure follows the W3C VC data model v1.1: The `@context` array contains the core context and extended context, such as `"<-URL-> / ns / credentials / v2"`; the `type` array declares the credential primary type and specific type, such as `["VerifiableCredential", "KYCVerificationCredential"]`; the `issuer` field is filled with the issuer's DID, which must be registered on-chain and have a valid `assertionMethod` public key; the `credentialSubject` object contains the user's DID and attribute key-value pairs. The attribute values ​​can be directly obtained from the raw data extracted by TLSNotary, or they can be processed through zero-knowledge scope proofs (such as proving age ∈ [18, 120] without revealing the specific value); the `proof` object contains `type` (JsonWebSignature2020), `created` (ISO8601 timestamp), `verificationMethod` (issuer's public key reference), `proofPurpose` (assertionMethod), and `jws` (JWS compact serialization signature).

[0083] EAS On-Chain Anchoring Mechanism: EAS (Ethereum Attestation Service) provides schema registration and proof issuance functions. This embodiment pre-registers the following schemas in EAS: When the publisher calls the attest function, the parameters include: schemaUID: The ID of the pre-registered schema mentioned above; recipient: The address of the credential holder (which can be parsed from the DID document); data: ABI-encoded tuple (shcemaUID, keccak256(credentialJSON), block.timestamp, expiration, msg.sender); refUID: An optional ID that references other proofs for building a proof chain.

[0084] After verifying the existence and validity of the DID corresponding to the issuer's address, the EAS contract writes it to the on-chain state and returns a unique attestation ID. This ID is added to the service array of the DID document. (6) Verification query module.

[0085] The verification query module provides standardized verification interfaces for third parties, which can be implemented using either on-chain contracts or off-chain services.

[0086] On-chain verification mode: Suitable for scenarios involving direct verification of smart contracts, such as DAO voting. The verification contract interface is defined as follows: Implementation logic: 1. Call the DID registration contract to obtain the DID record and check the isActive flag; 2. Parse the serviceEndpoint from the DID document URL and extract the EAS attestation ID; 3. Call the EAS contract to read the attestation and verify that the issuer's DID is valid and has not expired; 4. Load the complete credential JSON from IPFS, recover the issuer's public key using EIP-712 standard structured hashing, and verify the JWS signature; 5. Check that credentialSubject.id matches didIdentifier; 6. Extract the age attribute, verify that it is ≥18, and return true.

[0087] Off-chain verification mode: Suitable for Web2 applications or scenarios requiring high performance. The verification service provides a RESTful API: The service backend executes similar on-chain logic, but can cache DID documents and credentials, use RPC batch calls to improve efficiency, and return verification results and resolvable verification paths (including links to all intermediate proofs) for auditing.

[0088] See Figure 3 The flowchart for generating and verifying verifiable credentials is divided into two sub-processes. The first part is the credential generation process, which focuses on the details of the TLSNotary three-way handshake protocol, the notarization certificate generation mechanism, and the construction and on-chain anchoring process of W3C standard credentials. The second part is the credential verification process, which shows how the verifier starts from the DID identifier and completes the discovery, acquisition, signature verification, and attribute extraction of credentials through the on-chain registry, IPFS storage, and EAS contract, ultimately using them for business decision-making in a complete closed loop.

[0089] Example 2 Building upon Example 1, this example provides a lightweight, decentralized identity authentication method that employs OIDC self-authentication. The following details the entire DID registration process based on the OIDC channel, illustrating how to securely establish a cryptographic binding between Web2 identity and DID without the involvement of a centralized server.

[0090] Step 1: Environment Preparation and Key Generation. User Alice downloads and installs the client application of this invention (iOS / Android / browser plugin). Upon first launch, the application prompts her to create an identity. Alice clicks "Create," and the application performs the following operations: Call SecRandomCopyBytes (iOS) or / dev / urandom (Android) to generate a 128-bit random seed; use the BIP-39 vocabulary to convert the seed into 12 mnemonic words, and the application forces Alice to write a backup by hand; derive the master key from the seed, and then generate a signature key pair (sk_Alice, pk_Alice), where pk_Alice is represented in hexadecimal as "0x04a7b2c9d8e1f3..." (130 bytes uncompressed format).

[0091] Step 2: DID Identifier and Document Construction. Alice chooses to use a third-party platform account for authentication, and the application automatically constructs a DID identifier for her: method = "oidc" chain-id = "polygon" username = "alice2023" timestamp = current Unix timestamp 1703980800 did = "did:oidc:polygon:alice2023-1703980800" Application assembly DID document: The application serializes the document into a string, uploads it via Infura's IPFS API, obtains the CID: "QmXkF3c4D9e6B8a7...", and constructs the document URL: "ipfs: / / QmXkF3c4D9e6B8a7...".

[0092] Step 3: OIDC Authorization Request Construction. The application launches the system browser and loads the following URL: Alice completes the login authorization for the third-party platform in the browser, and the third-party platform returns an ID Token. The application captures the token and begins local verification.

[0093] Step 4: Local ID Token Verification and ZK Circuit Input Preparation. The application performs the following verification steps: Get kid="190ad46eef97171d26c44976197eefb6993ab1794" from the Token header; Download the JWK Set from the third-party platform (get the jwks_uri from} / .well-known / openid-configuration). Find the corresponding RSA public key for kid, the modulus n, and the exponent e; Use the RSA-PSS algorithm to verify whether the signature matches the SHA-256 hash of header.payload; After successful verification, the payload is parsed, and sub="<-PHONE-><-PHONE->", nonce="0xf8b9c0d1e2f3f4...", iss="<-URL->", aud="alice-mobile-app...", and exp=<-PHONE-> are extracted.

[0094] The application checks that the exp has not expired, matches its own client_id with aud, and iss is a trusted third-party platform; the verification passes.

[0095] Step 5: Zero-knowledge proof generates a pre-compiled zk-SNARKs proof key for the application. The proof key corresponds to the following circuit logic (pseudocode description): The application uses the ID Token as the witness input circuit, with the public input being: did = "did:oidc:polygon:alice2023-1703980800" nonce_hash = SHA256("0xf8b9c0d1e2f3f4...") block_height = 45678901 (Current Polygon block number) The application runs the proof generation algorithm locally (based on the Bellman or Plonkish proof system), generating a proof object (containing three group elements π_A, π_B, and π_C) and a binding_commitment (the coordinates of an elliptic curve point) after about 4 seconds.

[0096] Step 6: Register a Polygon transaction on-chain, submit the application build, and sign it. To: DIDRegistryContract address (0x1234...) data: encodeFunctionCall("registerDID", did="did:oidc:polygon:alice2023-1703980800", documentUrl="ipfs: / / QmXkF3c4D9e6B8a7...", authType=0,authHash=sha256(id_token), zkProof=proof, bindingCommitment=binding_commitment ) gasLimit: 250000 gas price: 50 Gwei Alice confirms the transaction, and the application submits it to the Polygon network via WalletConnect or the built-in wallet. Contract execution: 1. Verify zkProof: Call the verifier contract, input proof and publicInputs=[did, nonce_hash, block_height], perform a pairing check, and return true; 2. Verify the output of the binding_commitment matching circuit; 3. Check that authHash is not being used; 4. Write the state map: didRegistry["did:oidc:polygon:alice2023-1703980800"] ={ documentUrl: "ipfs: / / QmXkF3c4D9e6B8a7...", authType: 0, authHash:0x9a8b7c6d5e4f3..., createdAt: <-PHONE->, isActive: true} 5. Trigger event: emit DIDRegistered("did:oidc:polygon:alice2023-1703980800", "ipfs: / / QmXkF3c4D9e6B8a7..."); Step 7: Registration Completed and Subsequent Use. After transaction confirmation, Alice's DID officially becomes active. She can use this DID to log in to any Web3 application that supports this system. Applications verify Alice's identity in the following ways: 1. Parse Alice's did, extract method="oidc" and chain-id="polygon"; 2. Call the DID registration contract on Polygon, and query the isActive status and documentUrl of did; 3. Load the DID document from IPFS and extract the public key from the verificationMethod; 4. Use the public key to verify Alice's signature on the challenge message to confirm that she possesses the private key.

[0097] Throughout the entire process, Alice's third-party accounts were not disclosed to any third party, thus ensuring privacy. The sub value of her third-party accounts was bound by binding_commitment, but could not be deduced from on-chain data, ensuring anonymity.

[0098] Example 3 Building upon Example 1, this example provides a lightweight, decentralized identity authentication method that employs payment signature-based KYC for authentication. The following details the KYC-level DID registration process based on the payment platform V3 interface, focusing on how to leverage the legal validity of payment signatures to resist Sybil attacks.

[0099] Step 1: DID Identifier Construction and Environment Preparation. User Bob wants to use <-xxx-> and selects a payment authentication path. The client generates a key pair for him and constructs a DID identifier: method = "payment" chain-id = "eth" username = "bob_xxx" did = "did:payment:eth:bob_wechat-1703980800" Step 2: Payment Platform Configuration. Bob needs an account with payment functionality enabled. On the client configuration page, Bob enters: appid: "xxx<-PHONE->abcdef", mchid: "1601234567", APIv3 key: This key is protected by fragmentation technology. The client only stores the encrypted key fragments. Bob needs to enter the password to decrypt it when using it.

[0100] Step 3: Constructing and Sending the Unified Order Request. The client calls the unified order interface of the payment platform V3 ( / v3 / pay / transactions / jsapi) and constructs the following JSON request body: The `attach` field is strictly limited to 128 bytes, and the DID identifier is 47 bytes long, which meets the requirements. `total=1` means 1 cent.

[0101] Step 4: Payment Signature Generation and Callback Capture. After processing the request, the payment platform server returns a pre-payment transaction session identifier: The client uses the prepay_id to call the JSAPI to initiate payment. Bob confirms the payment within the payment platform client and enters his password to complete the transaction.

[0102] After successful payment, the payment platform server sends a POST callback notification to notify_url, the body of which includes: Step 5: Payment Signature Verification and ZK Circuit Preparation. After receiving the callback, the client extracts the sign field. The calculation rule for sign is: 1. Sort all parameters in the XML except for `sign` by their ASCII names in ascending order; 2. Concatenate them into a string `stringA` using URL key-value pairs; 3. Append the merchant's APIv3 key to the end of `stringA` to obtain `stringSignTemp`; 4. Perform an HMAC-SHA256 operation on `stringSignTemp` to obtain `sign`. The client reproduces this process using the locally stored APIv3 key to verify that `sign` matches and confirms that the notification comes from the official payment platform. Simultaneously, it extracts the value of the `attach` field and verifies that it equals the target DID identifier to ensure the proof matches the current registration intent. Figure 1 To.

[0103] Step 6: Zero-Knowledge Proof Generation (Dedicated Circuit for Payment Path). The ZK circuit logic of the payment path differs from that of the OIDC path; its core function is to verify the validity of the payment signature. Bob uses the callback XML and APIv3 key as witness inputs, with the public inputs being: did = "did:payment:eth:bob_xxx-1703980800" attach_hash = SHA256("did:payment:eth:bob_xxx-1703980800") mchid = "1601234567" Generate proof locally that the payment callback contains the target DID and that the signature is valid.

[0104] Step 7: On-chain registration. Bob submits the registration transaction, calling the registerDID function of DIDRegistryContract, with authType=1 indicating the payment path. After the contract verifies the ZK proof, it writes the DID record.

[0105] Step 8: Quantitative Analysis of Sybil Attack Resistance Assuming an attacker attempts to register 10,000 fake DIDs: Each DID requires one payment, even if it's just 1 cent, the total cost is 100 yuan; After payment, the attacker needs to wait for a refund. The attacker needs to provide 10,000 valid merchant IDs, each of which needs to be real-name authenticated and linked to a bank card, costing far more than 100 yuan. If the risk control system detects frequent payments from the same device / IP / entity within a short period of time, it will trigger restrictions, causing the attack to fail.

[0106] Therefore, this channel's resistance to Sybil attacks is superior to most CAPTCHA or email verification schemes, and is close to traditional financial-grade KYC.

[0107] Example 4 This embodiment, based on embodiments 2 and 3, provides a decentralized identity authentication method with a lightweight architecture. The difference is that it also includes the process of using the TLSNotary oracle to obtain Web2 data and generate verifiable credentials. The following uses TLSNotary to obtain user asset proof from the Web2 platform (taking a simulated bank website as an example) and generate verifiable credentials that conform to the W3C standard, fully demonstrating the technical details of the credential generation process.

[0108] Step 1: User initiates an asset proof request. User Carol wants to add asset proof credentials to her DID for credit lending via DeFi protocols. She selects Bank of Web3 as the data source on the client and requests proof that her account balance is greater than 10,000.

[0109] Step 2: TLSNotary Session Initialization. Carol's client, the Bank of Web3 server, and the TLSNotary node establish a three-way session: 1. The client requests a session ID from the TLSNotary node, and the node returns session_id="sess_0xabcd1234"; 2. The client and the Bank server begin a TCP handshake. The ClientHello message carries the session_id extension, indicating support for third-party notarization. 3. The TLSNotary node captures ClientHello and ServerHello messages at the network layer using DPDK or eBPF technology and extracts: client_random: 0x1234... server_random: 0x5678... key_share: The coordinates of the ECDH public key point between the client and the server; 4. TLSNotary calculates the hash of the handshake parameters, handshake_hash = SHA256(client_random || server_random || key_share), stores it in the local database, and returns a handshake proof, handshake_proof, to the client (containing TLSNotary's signature of the hash).

[0110] Step 3: User Login and Data Request. Carol logs into Bank of Web3 in the client-side embedded WebView, enters her username and password, and completes authentication via HTTPS. The authentication cookie is automatically managed by the client. Subsequently, the client constructs an API request: The request was encrypted at the TLS layer, and the client recorded the request sequence number seq_num=5.

[0111] Step 4: Receive the encrypted response and notarization application. The Bank server returns an HTTP response (TLS record layer type: Application Data). The client receives the encrypted message and extracts: encrypted_record: Ciphertext of the TLS record layer; nonce: IV value of TLS 1.3; auth_tag: Authentication tag in GCM mode; seq_num: 6 (response sequence number).

[0112] The client packages and sends the following data to the TLSNotary node: Step 5: TLSNotary Notarization Certificate. The TLSNotary node is generated and the following verifications are performed: 1. Verify the validity of the handshake_proof signature to confirm that the session was issued by this node; 2. Using the recorded key_share, client_random, and server_random, reproduce the pre-master secret calculation process (the node does not have the client's private key and cannot complete the final key derivation). 3. Calculate the server handshake secret and server application secret using the TLS 1.3 key derivation function (HKDF-Expand-Label); 4. Use the server application secret to decrypt the encrypted_response and verify that the auth_tag is valid; 5. If decryption is successful, parse the JSON and extract balance=15420.50; 6. Generate a notarized receipt: Where response_commitment = SHA256(serialize(response_data)), and merkle_root is used to support selective disclosure in zero-knowledge proofs.

[0113] Step 6: The issuer constructs the W3C credential. Carol selects a DeFi protocol as the issuer (issuer="did:payment:eth:defi-protocol"), which runs the issuance process on a trusted server. After the program receives Carol's request and the TLSNotary notarized receipt: 1. Verify the signature on the notarized receipt and confirm that notary_id is in the trusted list; 2. Verify merkle_proof to confirm that response_commitment corresponds to merkle_root; 3. Decrypt or obtain the plaintext response from Carol, and verify that balance >= 10000; 4. Construct W3C credentials: Step 7: EAS On-Chain Anchoring and DID Document Update. The issuer calculates the Keccak-256 hash of the credential JSON: credentialHash = keccak256(serialize(credential)), and calls the EAS contract: The attestation ID was obtained as "0xabcd1234...".

[0114] The publisher assisted Carol in updating her DID document by adding the following to the service array: The updated document is re-uploaded to IPFS with a new CID of "QmNewHash...". Carol calls the updateDocument function of DIDRegistryContract to update the on-chain record.

[0115] Step 8: On-chain verification of the DeFi protocol. When Carol applies for a credit loan, the DeFi protocol's smart contract executes: 1. Parse Carol's DID and obtain the documentUrl; 2. Load documents from IPFS, iterate through the service array, and find records with type LinkedVerifiableCredential and matching issuer; 3. Read the attestation ID "0xabcd1234" from the EAS contract and verify the issuer address and expiration time; 4. Load the complete credential JSON from IPFS and verify the JWS signature; 5. Extract credentialSubject.balanceThreshold = 10000 to confirm that Carol meets the minimum asset requirement; 6. Calculate the credit limit based on balance=15420.50 and issue the loan.

[0116] Throughout the process, Carol's original bank account information was not disclosed to the DeFi protocol; it was only proven that she met the asset threshold, thus achieving the "principle of minimum information disclosure".

[0117] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for decentralized identity authentication with light architecture, characterized in that, Comprise the following steps: Generate a public-private key pair locally and construct a DID identifier, assemble a DID document and upload to decentralized storage; Return Web2 authentication information to achieve DID binding through OIDC authentication or payment signature KYC authentication with a user-specified third-party platform; Based on the Web2 authentication information, verify through the local zero-knowledge proof circuit, bind the DID identifier and document address on-chain to achieve identity authentication.

2. The method of claim 1, wherein, The process of OIDC authentication comprises the following steps: Embed the DID identifier in the nonce field and build an OIDC authorization request adapted to the third-party platform; After the user completes the login authorization on the third-party platform, obtain the Web2 authentication information returned by the third-party platform; Based on the ID Token in the Web2 authentication information, perform kid analysis, public key acquisition, and signature verification to complete DID binding.

3. The method of claim 2, wherein, Under the premise of using OIDC authentication, the process of verifying through the local zero-knowledge proof circuit comprises the following steps: Take the ID Token in the Web2 authentication information as a private input, take the DID identifier, nonce field hash, and current block height as inputs, perform Token signature verification, payload verification, Token metadata verification, and nonce binding verification, in response to all verifications passing, encrypt the user field in the Web2 authentication information, combine the DID identifier to output a commitment for on-chain verification.

4. The method of claim 2, wherein, Under the premise of using OIDC authentication, the process of binding the DID identifier and document address on-chain comprises the following steps: Based on the commitment output by the zero-knowledge proof circuit, build and sign a transaction request; After user confirmation, submit the signed transaction request to the transaction network, and after verification and inspection, achieve DID identifier and document address binding on-chain.

5. The method of claim 2, wherein the method is a light-weight architecture for decentralized identity authentication. Under the premise of using OIDC authentication, it also includes the following DID login process: Send the DID identifier and transaction network ID to the third-party Web3 platform to be logged in, and after the third-party Web3 platform calls the corresponding transaction network to query the corresponding DID state and document address, obtains the DID document from the decentralized storage and extracts the public key for verification, it achieves DID login.

6. The method of claim 1, wherein, The process of payment signature KYC authentication comprises the following steps: After the user configures the information of the third-party platform, embed the DID identifier in the attach field, build a request and send it to the order interface of the third-party platform; Obtain the prepayment transaction session identifier returned by the third-party platform, and after the user completes the transaction, obtain the callback notification, and after signature matching verification, it is used as Web2 authentication information.

7. The method of claim 6, wherein, Under the premise of using payment signature KYC authentication, the process of verifying through the local zero-knowledge proof circuit comprises the following steps: Take the callback notification in the Web2 authentication information as a private input, take the DID identifier, hash of the attach field, and merchant number as public inputs, perform XML parsing, merchant number matching verification, payment state verification, attach field verification, and signature verification, and in response to all verifications passing, encrypt the merchant number in the Web2 authentication information, combine the DID identifier, and output a commitment for on-chain verification.

8. The method of claim 6, wherein the method is a light-weight architecture for decentralized identity authentication. On the premise of adopting payment signature KYC authentication, the process of binding the DID identifier and the document address on the chain includes the following steps: After completing the zero-knowledge proof of the commitment on the chain, write to the DID record; Return the funds of the transaction.

9. The method of claim 1, wherein, Also includes the process of obtaining verifiable credentials based on the TLSNotary oracle: Select a data source platform and a target for requesting proof, and initiate an asset proof request; Establish communication with the data source platform and the TLSNotary oracle node, and obtain a handshake proof through three-party notarization; Log in to the data source platform, construct a client request, and send it to the data source platform; Receive the encrypted message from the data source platform, extract the TLS record layer ciphertext, nonce field, GCM mode authentication tag, and response sequence number, package and send to the TLSNotary oracle node; The TLSNotary oracle node verifies the handshake proof and decrypts it to generate a TLSNotary notarization receipt; Send the TLSNotary notarization receipt to the issuer platform, and construct a W3C credential; The issuer platform calculates the hash of the W3C credential and updates the on-chain DID record; Realize on-chain verification.

10. A light architecture decentralized identity authentication system, characterized in that, The system for implementing the decentralized identity authentication method according to any one of claims 1-9 includes: A user-end autonomous module for generating a public-private key pair locally and constructing a DID identifier, assembling a DID document and uploading it to decentralized storage; A Web2 authentication adaptation module for returning Web2 authentication information to realize DID binding through OIDC authentication or payment signature KYC authentication with a user-specified third-party platform; A zero-knowledge proof module for verifying based on the Web2 authentication information through a local zero-knowledge proof circuit; An on-chain registration module for binding the DID identifier and the document address on the chain to realize identity authentication; A verification query module for DID document parsing and credential retrieval, as well as cryptography verification and attribute extraction; A credential management module for TLSNotary oracle handshake and W3 credential format packaging to realize EAS on-chain evidence.

Images