You may want to consider using the Web Cryptography API. Then, you can store the user's private key in the CryptoKey object, with the .extractable property set to false. This way the private key can only be used for decrypting and/or signing messages within the browser - but can not be read (even by client-side scripting in the browser).
It depends on the header, and on what the library is designed to handle. Let me go through each header and explain if it would make sense or not:
Does specifying Content-Type make sense?
Yes and no. It's certainly nice for the server to tell us that the response is in JSON, but it is by no means a requirement. It would make sense to throw an exception if ...
Anything stored client side (and not encrypted) can be seen and/or modified by the user.
The usual way of implementing a "Remember Me" functionality is to set a cookie with an encrypted username, sent from the server.
The server will encrypt the username with a secret key, known only to the server, and set a cookie with that value. When the server later ...
I can see two options here.
The first is to just delegate the crypto part to a server, and communicate with it via a HTTP API. This wouldn't involve the JS web crypto API, and perhaps it would violate some of your design criteria.
Second option for communicating across origins is Window.postMessage(). It let's you send messages and receive responses ...