To provide a little more background on @bc-pi comments, a JWT is the compact serialization (base64 URL encoded) of a JWS. There is also a JSON serialization format that I have never myself seen in the wild.

I agree also with Brian's comments around having the JWT in a header sometimes and a body sometimes. A key requirement in the design of JWT was that it could be included in an HTTP header without additional encoding (and also in a URL)

In my opinion, browser related protocols should "stay in their lane" and use headers rather than the body

Thanks for good suggestions! Agree that the current handwaving is potentially misleading. In all cases we mean the normal compact serialization.

Also agree we should be consistent on header vs body. Tbh I'm not totally sure where Sec-Session-Response came from, but Dick your feedback on staying with header is duly noted!

Yes, I will update to use headers. We went back and forth between body and header internally with the unfortunate result that we got one of each. Thank you for the feedback, will update.

One reason I personally think headers are better is that doesn't interfere with other body content.

But it's worth maybe a couple more words. "How Body". Will it handle JSON, XML, gRPC, or some other binary format.

While it is the one body thing, what happens when there is a second property or third property that we realize, oops we need this and it doesn't belong in the JWT. Then we are stuck. Unless the body is going to be plain unencoded application/json.

But since we are actually attempting to authorize the request, the authorization header already exists to send JWTs like this generated by the signer, that would be the most consistent with how many services validate incoming JWTs. If