xori

I understand, but things like https://github.com/GoogleChromeLabs/comlink enable it. Similar to how iFrames don't have access to their parent page you need a facilitator. My question is why not use a js facilitator that could work in all browsers, rather than just Chrome.

I find it an interesting choice that the author decided to invest in new iFrame technology rather than existing multi-thread technology in the browser.

Comment · 2 years ago

I see it now, I don't know how I missed it.

Comment · 2 years ago

Why reach for iFrames over other technology like WebWorkers?

Comment · 2 years ago

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...

Comment · 2 years ago

When you `.get` a credential you can provide a challenge that it signs which you can make the JWT. With an added bonus that this passkey can exist on your phone or password manager which you can use to authenticate on a different device while still feeling confident in it's security.

Comment · 2 years ago

Yeah that does it for new keys generated, any old keys in IDB obviously still are exposed.

Comment · 2 years ago

Rather than generating key data on the client in the open, and storing it in IDB, I would recommend the Credential Management API[0]. Hand off the responsibility to proper generation and storage to the user agent. Then do your signing of the JWT with them instead.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Credential_...

Comment · 2 years ago

so I don't fully understand what you're preventing

    const db = await openDatabase();
    const keyPair = await getKeyPair(db);
    await crypto.subtle.exportKey("jwk", keyPair.privateKey)

exports the private key if I have a XSS vuln.

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?