[jwally]

> The recommendation for IP address in the JWT is good, but I don't understand your last recommendation of 1) sending the JWT, 2) additionally sending the base64 JWT in a header 3) sending the signature in the header. The crypto.subtle api only works on https domains so you're not defending against mitm attacks on unsecure networks either. And if we can't trust TLS what can we trust on the web?

So here I'm basically trying to describe what changes you would make to the way JWT validation is currently done. IIRC, the JWT goes over in the headers. I'm suggesting adding 2 headers - one with the base64 of the json of the JWT, the other header is the ecdsa signature of that.

This way, you know whoever it is that logged in and provided their signed public key, has to be sending this request because they signed it with the same key - which is locked to _this_ browser.

[xori]

I'm confident then that you can skip the base64 encoded header and just have the server use the jwt passed in the bearer token and the new signature you propose. (As the base64 encoded version can be reconstructed from the JWT itself)

But I think ideally I would use a wrapped JWT with `"alg": "ES256"` and just pass it as normal in a bearer token[0] as JWTs natively support signed primitives.

[0]: https://jwt.io/#debugger-io?token=eyJhbGciOiJFUzI1NiIsInR5cC...

[jwally]

tbh, I haven't worked with JWT's a _ton_, so apologies if there's an _obvious_ better way to do something, lol.

I think you're right. Just sign the JWT that's going over as a header (as its a string), and add a signature from the webcrypto pieces - and BAM! you can verify that the jwt came from who it was originally assigned to...unless I'm missing something.