Sessions can register from a subdomain without `.well-known` config?

[snandy-ts]

We're looking into how to configure our .well-known JSON so that subdomains of our origin can register new site-scoped sessions. However, the behavior we're seeing for registration doesn't seem to align with our expectations based on the spec.

Our .well-known config is currently empty, but we're able to register a site-scoped session for example.com from abc.example.com. We expected to need to list the subdomain as one of the registering_origins in the .well-known JSON. We're using appropriate root eTLD+1 origin and include_site=true values in our session config; furthermore, deleting the appropriate cookie and refreshing the page allows us to refresh the session in a call to https://abc.example.com/dbsc/refresh, which (alongside the browser histograms) confirms sessions are being recognized, registered, and refreshed.

Question: Is this behavior expected (i.e., should subdomains be able to register a site-scoped session for the eTLD+1 without being explicitly opted-in via the .well-known JSON)? Or should registration be blocked unless the subdomain appears in registering_origins field of the JSON?

I've copied some information about our session registration header and our session config below for reference.

Session registration header:

Secure-Session-Registration: (ES256 RS256); path="https%3A%2F%2Fabc.example.com%2Fdbsc%2Fstart"; challenge="challenge-value"

Response from https://abc.example.com/dbsc/start:

{
    "session_identifier":"1234",
    "refresh_url":"/dbsc/refresh",
    "scope":{
        "origin":"https://example.com/",
        "include_site":true
    },
    "credentials":[{
        "type":"cookie",
        "name":"cookie-name",
        "attributes":"Path=/; Domain=.example.com; Secure; HttpOnly; SameSite=Lax"
    }]
}

[drubery]

That would definitely be a bug in Chrome. It should not be possible per the spec.

But I suspect this is due to our developer settings. We recommend to set the #enable-standard-device-bound-session-credentials flag to "Enabled - For Developers", but this setting disables the .well-known checks. We assume that while prototyping, developers would not want to publish a .well-known. So if you're using that setting, I'd recommend trying with the regular "Enabled" option. Let me know if that fixes it.

If you need some of the "For developers" behavior but not all (e.g. ignoring the Origin Trial token), let me know and I can help you put together a command line argument with the correct behavior.

[snandy-ts]

Toggling the flag to "Enabled" did the trick! Is there an accessible list of features that are toggled on/off with the "Enabled for developers" setting?

Also, on a tangential note, the browser's call to the https://example.com/.well-known/device-bound-sessions includes no existing cookies for http://example.com, unlike how the cookies are attached to requests to the session registration/refresh endpoints. I couldn't find any note of this in the spec, so is this intended behavior?

[drubery]

Toggling the flag to "Enabled" did the trick! Is there an accessible list of features that are toggled on/off with the "Enabled for developers" setting?

Sorry about that! I've written down the developer checks here.

I couldn't find any note of this in the spec, so is this intended behavior?

This is an oversight in the spec, thank you! Fetching .well-knowns without cookies is fairly standard, but we should explicitly say that we're doing it.