Verified Identity Is Not Verified Intent: The Missing Link in Digital Trust

Ahead of his trip to the Global Digital Collaboration Conference in Geneva, Ditto CPO, Matt Hornsey, highlights the criticality of one of the topics he is keen to discuss with other delegates – binding identity, authentication and intent.

A credential says something trustworthy about me.
An authenticator proves control of a key.
Transaction signing proves exactly what I agree to.
But trust requires binding all three.

That distinction is becoming increasingly important as digital identity, wallets and passkeys move into mainstream customer journeys.

Each can provide strong assurance. But assurance is not additive by default. A high-assurance identity credential plus phishing-resistant authentication does not automatically prove that the verified person, using the expected device, intended a particular action.

The missing piece is binding.

Assurance does not automatically transfer

Strong identity verification tells a relying party how confidently an identity was established. Strong passwordless authentication tells it something different: that the person interacting now controls a particular authenticator.

One does not inherit the assurance of the other.

NIST’s 2025 Digital Identity Guidelines (NIST SP 800-63-4) make this separation explicit through Identity Assurance Level, Authentication Assurance Level and Federation Assurance Level. The latest guidance also incorporates subscriber-controlled wallets into its federation model.

Good architecture therefore preserves where each proof came from, rather than reducing several independent signals to a single “verified” state.

The point of binding is the security boundary

The critical question is what happens when those proofs meet.

A service needs confidence that the credential holder, authenticator, customer relationship and device or wallet instance belong together. That relationship must also be bound to the correct relying party, session and purpose.

Without that binding, individually valid components can still produce a fraudulent outcome. An attacker may substitute an authenticator, relay a credential presentation or exploit a recovery path without breaking either underlying technology.

The point of binding is therefore the security boundary. It is where separate proofs become a trustworthy relationship — or where a gap between them becomes an attack path.

This is fundamentally a fraud prevention problem, not simply an authentication problem.

Recovery reveals the real assurance level

Security architecture is often designed around enrolment and login. Attackers are equally interested in what happens afterwards.

Can a synced passkey appear on a new device? What happens when a wallet moves? Can a credential establish a replacement authenticator? How is an old binding revoked?

Identity recovery cannot become a shortcut around the controls established during enrolment. The assurance of the system is ultimately constrained by its weakest recovery path.

Privacy makes binding harder — by design

The easiest way to maintain continuity is a persistent identifier. It is also a straightforward way to enable tracking across services.

The better goal is continuity inside a legitimate customer relationship without creating a universal correlation identifier.

That makes selective disclosure, pairwise identifiers and purpose-specific consent important architectural tools. The European Digital Identity framework – EU Regulation 2024/1183 – explicitly requires selective disclosure and mechanisms for authenticating relying parties when using an EUDI Wallet.

Privacy and assurance are not competing outcomes. They have to be designed together.

Authentication has to reach the action

Login is rarely the highest-risk moment.

Changing a beneficiary, recovering an account, issuing a credential or approving a payment carries more consequence. For these events, transaction signing should bind authentication to the exact context: what action, which recipient, what amount, which service and when.

The FIDO Alliance’s work on Secure Payment Confirmation illustrates the principle: cryptographic authentication can include the transaction details the user is explicitly approving.

That is the shift from proving presence to proving intent.

An effective identity orchestration platform should not flatten identity, authentication and authorisation into one opaque measure of trust. It should preserve their provenance and connect them when risk demands it.

Do not turn every wallet presentation into a login. And do not mistake every passkey for proof of identity.

The stronger architecture keeps these proofs distinct — then binds the person, channel and action into one continuous chain of trust.