Max-Age cookie attribute in JSON session credentials resulting in registration failure

[e-aakash]

Hi
The example in JSON Session instruction currently mentions that Max-Age and Expires attributes are ignored, and also mentions that it SHOULD match attributes used in Set-Cookie.

    "attributes": "Domain=example.com; Path=/; Secure; HttpOnly; SameSite=None"
    // Attributes Max-Age and Expires are ignored

However, on using Max-Age in Set-Cookie and in json session credentials, registration fails with code 70 kInvalidCredentialsCookieUnpermittedAttribute (possibly due to restricting attributes to only contain domain, path, secure, httponly and samesite in https://source.chromium.org/chromium/chromium/src/+/main:net/device_bound_sessions/cookie_craving.cc;l=128).

Using Max-Age in Set-Cookie but not in the credentials results in successful session registration.

What is the expected usage of max-age? Should it be set only on Set-cookie and not added in credentials? If so, can we update the spec to mention that only these attributes are permitted in the credentials section?

Let me know if any other info is required.

Thanks!

[drubery]

Ah, the language here is kind of confusing.

What the language in the spec is supposed to mean is "Max-Age and Expires don't count when we compare the cookie attributes in the payload and the cookie attributes on request cookies". I think that's clearly the right behavior, so I'll follow up just to clarify the language.

Separately, Chrome has implemented a check (kInvalidCredentialsCookieUnpermittedAttribute) to be fairly strict with the attributes field. We want to make sure that developers don't specify any attributes in the session config that don't actually do anything. For example, we don't want anyone to include this line in their session config:

    "attributes": "Domain=example.com; Max-Age: 600"

and think that means that DBSC will ensure a cookie with a Max-Age of 600 is attached to the request, and therefore believing if the cookie Max-Age is 300 Chrome would do a refresh.

You should be able to pass that check by just not including Max-Age in your session config.

[e-aakash]

Just to understand the behaviour of the cookie refresh, the max-age included in the Set-Cookie is honoured by the browser for performing the refresh, or is this understanding incorrect?

What is the reason to not have them in the attributes in credentials? Is is just for decoupling the cookie and dbsc session/handling?
Even though this is not handled by the dbsc implementation, the cookie handling in the browser will ensure to not use the cookie after the max-age, right?

You should be able to pass that check by just not including Max-Age in your session config.

Confirming again, it has to be set in the Set-cookie header, to get the correct behaviour of short lived dbsc cookie?

[drubery]

What is the reason to not have them in the attributes in credentials? Is is just for decoupling the cookie and dbsc session/handling?

The credentials field is specifying what cookies must be included on in-scope requests. So the semantics of those entries are really a kind of "matcher" that runs on the request cookies. The spec lets us specify certain kinds of matchers (on Domain, Path, etc), but not on Max-Age. Chrome is then strict about ensuring that you only request matchers that actually exist.

That's just to avoid sites expecting that certain matchers exist and being surprised when that field in the attributes doesn't do anything.

Confirming again, it has to be set in the Set-cookie header, to get the correct behaviour of short lived dbsc cookie?

Yes, DBSC makes no changes to cookie semantics. You should include Max-Age on your cookies as normal so they expire.