DEMO AUTHENTICATION
01 / 04
Demonstration credentials only. No real account or password is involved.
01 SESSION CONTINUITY / DEVICE BINDING
Keep the session
close to the device.
A small, inspectable demonstration of a login session that can only keep refreshing when the browser can prove possession of its device-protected key.
02 LIVE SESSION / OBSERVABILITY
You are logged in.
The account page is ordinary HTTP. The credential underneath it may be device-bound.
SESSION STATUS
Checking DBSC registration
Waiting for the browser to call the registration endpoint and prove its key.
DEVICE-BOUND SESSION
PENDING
SESSION IDENTIFIER
Awaiting registration
BOUND COOKIE
Not issued
LAST REFRESH
—
REFRESHES
0
ALGORITHM
ES256
THE SHORT VERSION
WHY IT MATTERS
Bearer cookies are replayable. If someone copies one, possession is normally enough to use it elsewhere.
DBSC adds a session-specific key pair. The browser protects the private key — with hardware-backed storage such as a TPM where supported — while the server keeps the public key.
The authentication cookie stays short-lived. When it expires, Chrome pauses the request, proves it still has the private key, gets a new cookie, and resumes.
DBSC does not stop malware already controlling the device or browser. It is complementary to passwords, MFA, passkeys, and WebAuthn.
INSPECT IT YOURSELF
CHROME DEVTOOLS
- 01
Open Chrome DevTools.
- 02
Select Application.
- 03
Expand Background services.
- 04
Select Device bound sessions.
- 05
Watch creation, challenge, refresh, and termination events.
- 06
Use Network to inspect the DBSC headers.
EVENT TIMELINE
THIS SESSION ONLY
Events will appear after login.
Only event names and timestamps are shown. Proofs, cookies, challenges, and keys stay server-side.
DBSC is a W3C Editor’s Draft — not an RFC or finalized W3C Recommendation. This site is an educational demonstration.