Warren Parad

Okay, well that can be fixed by specifying the algorithm as the parameter value rather than the key. `Header: alg=ES256`

It's important clarify when we say client whether or not we mean the site or the user device. If we are talking about the users device is compromised, can you...

Exactly, as long as we only trust header JWTs that include a timestamp or we can go even further, that include the sessionId then even having access to call the...

But that's Soo much extra complexity for everything to solve arguably a very corner case

> Can you expand on what you consider a corner case? > > See [this article](https://blog.google/threat-analysis-group/phishing-campaign-targets-youtube-creators-cookie-theft-malware/) for some specific types of malware we want to address. In our experience, these...

> How long should the server trust the hash? What prevents a malware from simply stealing the hash once and using that forever? Because the session cookie value will change...

Great now we are getting somewhere. Is there a reason why the solution can't be considered a trivial implementation detail for the devices to solve? For instance, a naive solution...

I'm not totally following why the server would need to do that, the Session Cookie would be sent with the Signed Hash on Refresh, and the Access Token used with...

I see what you are saying, that is sort of why I asked if there was a non-malicious flow that would still be rate limited. But I assume an argument...

> So in the general case, we have to assume such malware can just make up whatever timestamps they want signed. Right, which is why the suggestion was to sign...