How do servers manage the public keys and the sessions?

[hdfrk]

The concept of DSBC seems very interesting from a point of view of protecting users from the cookie theft.

Although, I came up with two questions, regarding the server side.

1. How would the servers manage the public keys from the browsers? Don't they need implementations nearly equal to those of WebAuthn RPs (FIDO servers)?
2. The concept of DSBC seems that the servers issue very short-lived session cookies when the browsers present the signed JWTs (please point out if I am misunderstooding). How should the servers manage sessions when providing services when there are browsers that are compatible with DSBC and not?

[arnar]

Servers would manage sessions more or less exactly as they do today. They can either maintain their long-term cookies as session identifiers (they just stop being session authenticators), or they can store session identifiers in the "session id" property in DBSC.

The public key would just be an additional attribute to the session. It should work both for servers that store their session state server side in a database or some caching infra, as well as servers that store session attributes inside an encrypted+signed cookie (or the DBSC session id).

The design here allows this flexibility in order to make adoption easier to fit to the various methods this is done today without too many changes.

For the second question: While support for DBSC is mixed, servers should essentially treat the binding as optional. E.g. the presence of a public key in their session state can indicate whether the session is DBSC-enabled. If it is not, continue accepting e.g. long-lived session cookies as usual; and if it is, then only accept the long-term session identifying cookie if it comes with a short-term DBSC managed cookie.

Servers can then integrate this as a signal in their auth policies and abuse detection. For example, a user without a DBSC-enabled session might need to reauth interactively for performing sensitive operations - while a user with a DBSC-enabled session does not. All that is up to servers to design specifically for their application.

[hdfrk]

Thanks so much arnar!
Although I am now curious about a part in the answer.
store session attributes inside an encrypted+signed cookie

As of my understanding, cookies are neither encrypted nor signed in the DSBC spec. Instead, a server issue a very short-lived session cookie once it receives a JWT signed by a browser and the validation succeeds. Is my understanding correct?

Also, it seems that there could be a remaining risk of attackers impersonating legitimate users if the cookie issued after the JWT valudation gets stolen and the attackers use under the length of "max-age" of the cookies. I would like to know the mitigation for such risk is to shorten the "max-age" as short as possible (e.g., a few minutes?).

Apologies for asking many things! Forgive me as I am very interested in DSBC since I am expecting it would be a great protection for users from cookie theft by DSBC!

[dickhardt]

wrt. store session attributes inside an encrypted+signed cookie I believe @arnar is referring to existing practices of encrypting and signing cookies that are done by servers

[hdfrk]

wrt. store session attributes inside an encrypted+signed cookie I believe @arnar is referring to existing practices of encrypting and signing cookies that are done by servers
Ah, got it! @dickhardt