Namespace Tessio.Verifier.AspNetCore

InMemorySessionStore: Default in-memory ISessionStore. Suitable for a single-process app, the demo, and tests. Production deployments swap in a distributed store (Redis, SQL, …).

ResponseEncryptionKeyProvider: Holds the verifier's response-encryption key pair. The public half is advertised to wallets via client_metadata.jwks; the private half decrypts direct_post.jwt (ECDH-ES) responses. ResponseEncryptionKeyStore creates one per authorization request, generated or, built with ResponseKeyDerivationOptions, derived so every instance can create it again.

ResponseEncryptionKeyStore: Holds one response-encryption key pair per session, for the lifetime of that session.

ResponseKeyDerivation: Derives a P-256 response-encryption key from a master secret and a salt, so any instance holding the master can recreate the key for a request from its salt alone, and no private key is stored anywhere.

ResponseKeyDerivationOptions: Makes ResponseEncryptionKeyStore derive each request's key from Master and a fresh salt kept in Salts, so the key outlives the process that created it.

TessioVerifierEndpointRouteBuilderExtensions: Maps the Tessio verifier endpoints onto an IEndpointRouteBuilder.

TessioVerifierSandbox: Sandbox completion for hosts that create sessions themselves (bypassing the built-in /start endpoint) but still want DEMO-style auto-completion. The /start endpoint enqueues into the background demo completer; a self-driving host never reaches that path, so its sessions would otherwise hang. This exposes the completion explicitly.

TessioVerifierServiceCollectionExtensions: Registration entry point for the Tessio verifier.

VerifierOptions: Configuration for the Tessio verifier, supplied via AddTessioVerifier(IServiceCollection, Action<VerifierOptions>).

WalletResponseVerifier: Default IWalletResponseVerifier. Parses a wallet response format-aware (from the session's request), then verifies each credential with expectations derived from that same request — audience from client_id, nonce, and the requested vct / docType — rather than from the process-wide VerifierOptions. Verifying against the session's own client_id is what makes the seam multi-tenant correct, and it also closes the app-wide-audience gap for the built-in callback endpoint, which routes through VerifyParsedAsync(VerificationSession, ParsedWalletResponse, CancellationToken). A response returned through the Digital Credentials API is verified by VerifyDcApiAsync(DcApiPresentationRequest, string, string, SecurityKey?, CancellationToken), with the same checks bound to the page's origin instead of a client_id.

IAttemptRecordingSessionStore: An ISessionStore that can record a response which failed verification without completing the session. Everything about a session's failed attempts, as opposed to its outcome, belongs here.

IResponseKeySaltStore: Keeps the salt each request's response-encryption key was derived from, keyed by that key's kid, so whichever instance receives the wallet's response can derive the key again.

ISameDeviceSessionStore: An ISessionStore that can run the same-device flow: a session bound to the browser that started it, whose verified presentation is held until that browser comes back with the response code the wallet's redirect carried. Everything about binding, holding and redeeming belongs here.

ISessionStore: Pluggable storage for verification sessions. The default implementation is in-memory; production deployments may swap in distributed stores (Redis, SQL, etc.).

IStateCorrelatingSessionStore: An ISessionStore that can look a session up by the OpenID4VP state value a wallet echoes in its authorization response. The live callback path requires this: state is the only correlation handle a wallet response carries.

IWalletResponseVerifier: Parses and verifies a wallet authorization response against the session it answers, using the expectations carried by that session's own request. This is the public multi-tenant seam: one process verifies callbacks for any number of tenants without reading the process-wide VerifierOptions, because each session's request already pins the audience (client_id), nonce, response mode and the requested format / vct / docType.

SameDeviceHold: What HoldAsync(string, VerificationResult, byte[], DateTimeOffset, CancellationToken) did.

SameDeviceRedemption: What RedeemAsync(string, byte[], byte[], CancellationToken) did.

VerifierMode: Operating mode for the Tessio verifier. Because no production EUDI wallets ship yet, these modes let a developer exercise the full request/session/result flow without a real wallet.