Chrome DBSC: Session marked as session_ended despite valid challenge response

[jimmylo16]

Chrome is marking DBSC sessions as session_ended during the refresh flow, even when the server correctly responds with a 403 Forbidden status and a valid Secure-Session-Challenge header in the expected RFC9651 Structured Field format.

Problem Description

During the DBSC refresh flow (Step 1: Challenge), Chrome sends a refresh request with Sec-Secure-Session-Id header, and the server responds with:

1. Status Code: 403 Forbidden (as per W3C DBSC §8.8)
2. Header: Secure-Session-Challenge: "challenge_token";id="session_identifier"
3. Body: Plain text "OK"
4. Headers: Cache-Control: no-store, Content-Type: text/plain

However, Chrome's net-export logs show session_ended instead of proceeding to Step 2 (Proof).

Expected Behavior

According to W3C DBSC specification §8.8:

• Status 403: Chrome should retry with cached challenge
• Chrome should proceed to Step 2 by sending Secure-Session-Response header with signed JWT

Actual Behavior

• Chrome receives the 403 response with Secure-Session-Challenge header
• Chrome marks the session as session_ended instead of proceeding to Step 2
• No Step 2 request is made to refresh endpoint (no Secure-Session-Response header sent)

Implementation Details

Challenge Header Format

The server constructs the Secure-Session-Challenge header as follows:

Secure-Session-Challenge: "DBSC-<random_string>";id="<session_identifier>"

Where:

• challenge_token is a plain string (e.g., "DBSC-m74paggdrt")
• session_identifier matches the session_identifier sent during registration
• Format follows RFC9651 Structured Fields: "string-value";param="value"

Response Headers

HTTP/1.1 403 Forbidden
Content-Type: text/plain
Cache-Control: no-store
Secure-Session-Challenge: "DBSC-m74paggdrt";id="3ab57e6b-d886-4cc8-801c-ec1db4403ac9"
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Secure-Session-Registration, Secure-Session-Challenge

Response Body

OK

Questions

1. Session Identifier Matching: The id parameter matches the session_identifier from registration. Are there any additional requirements for this matching?

2. Response Format: Is there any requirement for the response body format beyond plain text? The spec mentions 403 but doesn't specify body requirements.

3. Timing: Could there be a timing issue where Chrome marks session_ended before processing the challenge header?

4. Error Handling: What specific conditions cause Chrome to mark a session as session_ended during the challenge step?

Additional Context

• The registration flow works correctly (Chrome successfully registers the session)
• The session_identifier sent during registration matches the id parameter in the challenge header
• The issue occurs consistently, not intermittently
• Net-export logs confirm session_ended status

Thank you for your assistance, if you want I can provide even further details!

[thefrog-gh]

Hello! Could you try out enabling the chrome://flags entry "Device Bound Session Credentials (Standard) DevTools Debugging" and debugging this with the Chrome DevTools Application panel "Device Bound Sessions" section? I would recommend having "Preserve log" checked so that events are not cleared on navigation. You can click into events to see more details about why they might be failing. The DevTools implementation is still in progress but might be able to help.

EDIT: Please use the most recent Chrome Canary version possible (M146).

[jimmylo16]

Hi thanks for the answer, I installed the latest version with Chrome Canary

not sure if it is something related with the configuration, the register works properly, then 3 seconds after that a refresh happens

[thefrog-gh]

Can you check what you see if you select the "Refresh -- Error" row?

[jimmylo16]

sure, thanks for everything

[thefrog-gh]

Ah okay, there's a persistent HTTP error on refresh, but showing the details for why it's failing is not yet implemented in Dev Tools (coming soon!). If you scroll up to the session config, you can check whether the refresh URL that's configured is the one you're expecting.

If that doesn't help, to debug this you will want to do the following:

1. Easy first: See which HTTP error code your refresh request is hitting by visiting chrome://histograms/Net.DeviceBoundSessions.Refresh.Network.Result
2. More complicated if step 1 doesn't help enough: See the actual response body by doing a net log trace. Visit chrome://net-export to start a trace with "Include raw bytes (will include cookies and credentials)". In another tab, do your DSBC registration and failing refresh. Then go back to the net-export tab and stop logging. After that you can upload the trace file to the netlog_viewer (there's a link to it on the chrome://net-export page once you end the trace). In the Events tab, search for "dbsc_" and then you can look at the individual rows to see the actual DBSC requests and responses.

[thefrog-gh]

^ Sorry, please ignore that. I just realized you already did the net log export. Let me take a closer look.

[thefrog-gh]

Could you check in the net log export if there is a second request after the 403 that has a different response code? A 403 should not be causing a "Persistent HTTP error" fetch result. Visiting chrome://histograms/Net.DeviceBoundSessions.Refresh.Network.Result should also be able to answer that. We can also see from the DevTools events that the first challenge event is set, meaning Chrome did process a 403 challenge associated with this specific session.

[jimmylo16]

I only have one

[thefrog-gh]

Yes, I think it would be within the same row, you'd need to scroll down after you see the 403. And what do you see in chrome://histograms/Net.DeviceBoundSessions.Refresh.Network.Result?

[jimmylo16]

I changed the status code from 403 to 400 in this test in the refresh histogram I get this:

in the netlog I get this, (no second request after the first 400):

and this is what I get at the end of the URL_REQUEST

t=215378 [st=233] HTTP_TRANSACTION_READ_RESPONSE_HEADERS
--> HTTP/1.1 400
content-type: text/plain
content-length: 2
date: Fri, 06 Feb 2026 15:29:07 GMT
referrer-policy: no-referrer-when-downgrade
server: Tengine
access-control-allow-credentials: true
access-control-expose-headers: Secure-Session-Registration, Secure-Session-Challenge
cache-control: no-store
secure-session-challenge: "DBSC-okrzd61vw7";id="a642f859-6cd2-44a8-a5ca-fc3f2cd2afce"
x-envoy-upstream-service-time: 87
x-api-server-segment: legacy
x-envoy-decorator-operation: default.dbsc-api-demo:8443/*
x-nginx-host: i-013f1006238decbc5-10.53.185.52
x-nginx-pool: test.dbsc-api-demo.melifrontends.com
x-nginx-upstreamhost: 172.19.0.5:80
x-upstream-server: envoy
x-request-id: 329ca568-212f-4d49-a9bb-4ae5861caff8
x-request-device-id: a9351269-88cf-487d-91e8-d6ab876bfc7e
x-d2id: a9351269-88cf-487d-91e8-d6ab876bfc7e
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-cache: Error from cloudfront
via: 1.1 eafa30ac9eebc826d698b6b51868b24a.cloudfront.net (CloudFront)
x-amz-cf-pop: IAD55-P6
alt-svc: h3=":443"; ma=86400
x-amz-cf-id: iOvcgMbm_zg-NkODnkc3EbEQBu0ZFSENdQuShHWEc_h6-TIUNOApwA==
t=215378 [st=233] -HTTP_TRANSACTION_READ_HEADERS
t=215378 [st=233] NETWORK_DELEGATE_HEADERS_RECEIVED [dt=0]
t=215378 [st=233] -URL_REQUEST_START_JOB
t=215378 [st=233] +URL_REQUEST_DELEGATE_RESPONSE_STARTED [dt=0]
t=215378 [st=233] DBSC_REFRESH_RESULT
--> status = "session_ended"
t=215378 [st=233] -URL_REQUEST_DELEGATE_RESPONSE_STARTED
t=215378 [st=233] CANCELLED
t=215378 [st=233] -REQUEST_ALIVE

[thefrog-gh]

Please keep your regular 403. What do you see in chrome://histograms/Net.DeviceBoundSessions.Refresh.Network.Result in this case?

[jimmylo16]

in my architecture, the 403 is blocked by cloudfront but the 400 no, for this case only 400:

[thefrog-gh]

Sorry, I think I am not understanding. In your earlier comment and in the initial description you were able to have a 403 error code. The 403 is required for setting the DBSC challenge; using a different code like 400 will not work.

Can you help me understand why you have changed to 400 now when you were able to use 403 to set a challenge earlier?

[jimmylo16]

no, that image is from a 400, sorry, in my case, the 403 does not work because of infra requirements, so are you saying that this only apply for the registration, and the refresh MUST use 403?

either way, I am going to try to test with the 403

[thefrog-gh]

With the current spec/implementation, yes, a 403 is required to set a challenge during refresh. Here's the 403 docs within "Refresh procedure":

Are you able to share any more details about which conditions (e.g. a 403) are not feasible for your use case and why? I will check internally if it's possible to make this more flexible.

either way, I am going to try to test with the 403

Please let me know what you find.