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.
- Assurance is re-checked on each sensitive request.
- 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.
Session tokens and 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.
Session cookies are stolen. Refresh tokens are exfiltrated from browser storage. Long-lived agent tokens outlive the human that authorised them. A stack that checks assurance only at login keeps accepting that token until it expires.
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 passkey, this DPoP-bound possession proof, this carrier-line state, this VC status. A relying party can require the passkey to be hardware-bound.
Passkey binding, DPoP, carrier state, and credential status are checked in one request. A credential, a passkey session attestation, or a cascade receipt is a signed record you can verify later with the published keys.
- FIDO2 passkey binding checked with WebAuthn assertion at request time.
- DPoP (RFC 9449) proves the request-signing key is in-hand for this request.
- SIM-swap and porting status looked up with the carrier data provider on each check.
- W3C VC 2.0 / SD-JWT-VC presentation and status verified inline via OpenID4VP.
- CAEP/SSF cross-app session events dispatch revocation in-process.
Compliance evidence from signed attestations
NIST SP 800-63-4 defines Authenticator Assurance Levels (AAL1-3) and Identifier Assurance Levels (IAL1-3) as thresholds rather than fixed feature lists. A phishing-resistant passkey is the AAL2-shaped pattern. Requiring that passkey to be hardware-bound is the opt-in that matches the AAL3 hardware-authenticator pattern. The evidence for the corresponding audit is in the signed attestations.
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
Credentials, passkey session attestations, and cascade receipts are dual-signed: classical ES256 or ES384 plus a detached ML-DSA-65 signature. The detached ML-DSA signature covers the JWS signing input followed by `:qnonce:` and a quantum-seeded nonce that travels with the signature. Store the record and verify it later with the published keys.
Trust Center →Agent-ready by design
The same verification API secures human sessions, agent delegations, and A2A trust establishment.
Agentic identity →How PasskeyBridge works with your identity provider
PasskeyBridge sits in front of Okta, Entra, Ping, or OneLogin as an assurance verifier and handles per-request verification and evidence. User profiles, enrollment flows and federated tokens for downstream apps stay with your IdP, which keeps owning the identity lifecycle.
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. PasskeyBridge also checks signals that CAEP does not standardise, such as 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. Because the decision path is short, the boundary can move to more actions over time.
- What is the audit story?
- A credential, a passkey session attestation, or a cascade receipt carries the signals it consumed and the policy it applied, signed as a classical ES256 or ES384 JWS plus a detached ML-DSA-65 signature. The detached ML-DSA signature covers the JWS signing input followed by `:qnonce:` and a quantum-seeded nonce that travels with the signature. Verify it with the keys published in the tenant DID document.
- 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.