Core Concepts
To effectively use the DID Connect library, it's helpful to understand its main components and how they interact. This section provides a high-level overview of the fundamental concepts that power the authentication process. You'll learn about the roles of WalletAuthenticator and WalletHandlers, the concept of 'Claims', and the authentication flow.
A typical DID Connect interaction involves three parties: the user's browser, your application server, and the user's DID Wallet.
Authentication Flow#
The entire process, from a user scanning a QR code to your application verifying their identity, is known as the Authentication Flow. It's a well-defined sequence of requests and responses that ensures a secure, user-consented data exchange. Understanding this flow is key to debugging and customizing the user experience.
WalletAuthenticator#
The WalletAuthenticator is a core class responsible for the application's side of the cryptographic operations. You instantiate it with your application's wallet (its DID), information about your app (appInfo), and the blockchain it interacts with (chainInfo). Its primary jobs are to generate the deep link for the QR code and to sign the claims you request from the user, proving to the user's wallet that the request is authentic.
Learn more about WalletAuthenticator
WalletHandlers#
While WalletAuthenticator handles the 'what' (the signed data), WalletHandlers handles the 'how' and 'where' (the API endpoints). This class provides a set of Express.js handlers that you attach to your application. It automatically creates the necessary routes for the DID Connect protocol, such as generating tokens, checking session status, and receiving data back from the DID Wallet. It orchestrates the entire session lifecycle.
Learn more about WalletHandlers
Claims#
A 'claim' is a request for a piece of information or an action from the user. Instead of traditional scopes like read:email, DID Connect uses specific, granular claims. You can ask for a user's profile information, request them to sign a transaction, or ask them to present a Verifiable Credential to prove something. The library provides a variety of built-in claim types to cover common use cases.
By understanding these core concepts, you have a solid foundation for building applications with DID Connect. To see how they all fit together in practice, the next logical step is to explore each component in more detail.
Next Steps: Dive into the WalletAuthenticator documentation for a step-by-step breakdown of how to configure your application's identity and cryptographic functions.