Reduce latency by including refresh challenge

[dickhardt]

As I understand it, refreshing the cookies requires the browser to acquire a new challenge, sign it, and then present it

While the server can respond with a Sec-Session-Challenge header at any time, the logic to generate the challenge will be at the /securesession endpoint, not at other server end points

when responding to POST /securesession/start or POST /securesession/refresh, the server could include Sec-Session-Reffresh headers that have the same content as the Sec-Session-Challenge headers -- and the challenge and optional authorization would be used on the next refresh, removing one round trip in a refresh cycle

[mattjm]

So a similar pattern to rotating refresh tokens. Folks were discussing other options for reducing round trips in #12--you could add something like this to the simplified flow proposed there. It might further complicate handling concurrency once you move the logic out of the "special" registration endpoints but it shouldn't be insurmountable.

[drubery]

This is already possible with Sec-Session-Challenge, since we always sign the most recently provided challenge. If session registration serves a Sec-Session-Challenge, then every refresh has a cached challenge available. Now the refresh looks like:

• The first request includes the Sec-Session-Response header with a signature of the most recent challenge
• The first response issues cookies, and includes a Sec-Session-Challenge header for the next request.

This is admittedly hard to see from the explainer, but doesn't need any spec changes.