Identity assurance that persists past the login screen.
Most identity assurance ends the moment a session token is minted. PasskeyBridge re-verifies passkey binding, carrier state, DPoP possession, and credential validity on every request that matters, without storing primary identifiers.
- Per-request assurance, not per-session assurance.
- Signal fusion across passkeys, carrier, DPoP, W3C VC 2.0, and CAEP/SSF events.
- Aligns to NIST SP 800-63-4 AAL2 and AAL3 patterns with auditable evidence.
- Zero primary identifiers stored; hybrid classical plus ML-DSA-65 signatures.
Why session tokens are not assurance
The prevailing identity model treats the login moment as the assurance boundary. A session token is minted, an authorization decision is made, and the rest of the session inherits both. Every subsequent request assumes the assurance that was true at authentication is still true. It usually is not.
Session cookies are stolen. Refresh tokens are exfiltrated from browser storage. Long-lived agent tokens outlive the human that authorised them. And once a token is loose, nothing in a traditional stack notices—because nothing is checking.
What continuous assurance looks like in practice
PasskeyBridge sits in front of your IdP as a verification gate. Every request that matters—high-value action, agent delegation, credential presentation, cross-tenant call—is re-checked against a signed attestation of the current binding: this hardware-bound passkey, this DPoP-bound possession proof, this carrier-line state, this VC status.
The verification is fast because the state that matters lives at the edge and is fused into a single signed decision. It is auditable because every decision is a signed attestation with a JSON-LD context you can replay years later.
- FIDO2 passkey binding checked with WebAuthn assertion at request time.
- DPoP (RFC 9449) proves the request-signing key is in-hand for this request.
- Carrier tenure and port-out state pulled live, not from a signup snapshot.
- W3C VC 2.0 / SD-JWT-VC presentation and status verified inline via OpenID4VP.
- CAEP/SSF cross-app session events dispatch revocation in-process, not on a queue.
Compliance alignment without the paperwork tax
NIST SP 800-63-4 defines Authenticator Assurance Levels (AAL1-3) and Identifier Assurance Levels (IAL1-3) as thresholds rather than fixed feature lists. PasskeyBridge maps cleanly to the AAL2 and AAL3 patterns: hardware-bound, phishing-resistant, verifier-impersonation-resistant. The evidence needed for the corresponding audit lives in the signed attestations, not a separate compliance spreadsheet.
For teams working toward eIDAS 2.0 / EUDI Wallet interop or the ITU-T X.1811 assurance framework, the same attestation stream doubles as the trust anchor. We ship a zero-PII binding layer specifically for the EUDI Wallet integration model.
The PasskeyBridge approach
Signal fusion, one response
Passkey, DPoP, carrier state and VC status resolved in one request rather than a chain of async calls. Decision latency is recorded per request; a live carrier lookup adds the carrier network's own time on top.
Architecture whitepaper →Assurance as evidence
Every verification returns a signed, JCS-canonicalised attestation. Store it, replay it, and it verifies years later—including past the post-quantum transition.
Trust Center →Agent-ready by design
The same verification API secures human sessions, agent delegations, and A2A trust establishment. No separate stack for AI-mediated identity.
PIST and A2A →We are not an identity provider
PasskeyBridge does not store user profiles, run enrollment flows, or issue federated tokens for downstream apps. It sits in front of Okta, Entra, Ping, or OneLogin as an assurance verifier. Your IdP still owns identity lifecycle; we own the per-request verification and evidence layer. If you are shopping for an IdP, that is a different conversation. If you are shopping for assurance that persists past the token mint, this is that layer.
Frequently asked
- How is this different from continuous access evaluation (CAEP)?
- CAEP is an event-transmission protocol—an IdP publishes revocation signals and receivers consume them. PasskeyBridge is a CAEP receiver, but it is also the verifier that generates events based on live signal changes. CAEP is the transport; assurance is the substance. We do both, plus we cover signals CAEP does not standardise, like carrier state.
- Can we run assurance verification only on high-risk actions?
- Yes. The typical deployment applies continuous verification to a defined set of high-value actions (money movement, admin escalation, agent delegation, credential issuance) and leaves everything else on the session token. A decision path this short means the boundary can move gradually toward more actions without a UX cost.
- What is the audit story?
- Every verification decision is a signed attestation with the signals it consumed, the policy it applied, and a hybrid classical HMAC-SHA-256 + ML-DSA-65 signature. The attestation stream is the audit trail. It is replayable, JCS-canonicalised, and verifiable through the PasskeyBridge verification API.
- How does this align with eIDAS 2.0 / EUDI Wallet?
- Our zero-PII binding layer is the specific integration point for EUDI Wallet interop. We verify SD-JWT-VC presentations via OpenID4VP without persisting the underlying attributes, so a relying party gets the assurance signal without inheriting PII custodian obligations.
- Does agent-mediated action work under the same model?
- Yes. Agent-to-agent (A2A) trust establishment runs through the same verification API. The agent presents a delegated attestation (bound to a human or another attested agent), we verify the chain on the same path, and the decision inherits the same evidence properties as a human session verification.
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production. No demo booking required.