Skip to main content

Authentication

Passwordless authentication using EUDI Wallet credentials replaces passwords with cryptographic proofs. Instead of "something you know," users authenticate by proving they possess a valid credential and control its associated private key. This approach eliminates password databases, resists phishing, and improves user experience.

Prerequisites​

The authentication flow requires a credential containing an Account ID to already exist in the user's wallet. In Truvity's demo implementation, this credential is an Account Ownership Credential (AOC). Your organization defines the credential type and schema used for authentication in your own deployment. The credential is typically issued during an initial onboarding or registration flow (for example, after completing Know Your Customer (KYC) verification).

Flow overview​

Your organization acts as the Relying Party. You request the authentication credential from the user's wallet, and the Truvity EUDIW Connector handles the protocol exchange, verification, and result delivery.

The flow works as follows:

  1. The user initiates login in your app.
  2. Your app creates a presentation request for the authentication credential.
  3. The connector generates an authorization request and returns a URI.
  4. Your app displays a QR code (cross-device) or triggers a deep link (same-device).
  5. The user opens their EUDI Wallet, reviews the request, and approves with biometric authentication.
  6. The wallet signs a challenge with the credential's private key and submits the encrypted response.
  7. The connector decrypts, verifies the signature and key binding, and delivers the result to your callback.
  8. Your app matches the Key Binding Key Identifier (kbKeyId) to the user's account and establishes a session.

Recognizing returning users​

The Key Binding Key Identifier (kbKeyId) is a stable identifier derived from the credential's proof-of-possession key. It remains consistent across sessions for the same credential, allowing you to recognize returning users without storing personal data.

During the initial registration flow, you associate the kbKeyId with the user's account. On subsequent logins, the connector includes the kbKeyId in the callback, and your app matches it to the existing account.

Trust and security​

Key binding​

The wallet signs a unique challenge (nonce) with the private key associated with the credential. The connector verifies this signature, proving that the presenter is the same entity that was issued the credential. This is stronger than password-based authentication because the private key never leaves the user's device.

Service authentication​

The connector signs the authorization request using your X.509 access certificate. The wallet checks this certificate and displays your organization's verified name to the user before they consent. This prevents phishing because the user can confirm they're authenticating with the correct service.

Transactional data​

You can include contextual information (for example, "Login to Customer Portal") in the presentation request. The wallet displays this to the user and cryptographically binds it to the authentication proof, preventing the proof from being replayed in a different context.

Privacy and data minimization​

Authentication requests typically require minimal data: the credential with its Account ID and the key binding proof. You don't need to request personal attributes like name or date of birth for login if the kbKeyId is sufficient to identify the user.

The connector uses an ephemeral data model. Credential data is verified in memory, delivered to your callback, and then deleted.

Integration patterns​

Cross-device flow​

Common for desktop web apps. The user visits your website, scans a QR code with their EUDI Wallet, and your backend receives the authentication result through the callback.

Same-device flow​

Common for mobile apps. The user taps "Sign in with Wallet," the operating system opens the EUDI Wallet through a deep link, the user approves, and the wallet redirects back to your app.

Further reading​

  • Device binding—how cryptographic key binding proves the presenter legitimately possesses the credential
  • Connector architecture—system components, data flow, and how the connector delivers results to your callback
  • OID4VP protocol—how the OID4VP protocol enables credential verification between wallets and Relying Parties