How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
It’s like the initial authentication, where server and clientnexchange a symmetrical key with their asymmetrical keys. The difference is that in that exchange the server and the client meet for the first time whereas the point of pass keys is that once when you were already authenticated, you validated the device or whatever will hold the private key as a valid source, so then when the authentication code gets exchanged, both ends can verify that the other end is who they tell is, and both can verify the other end as valid, and thus that exchange authenticates you because you, in the past, while authenticated, trusted that device as valid.
Technically, yeah, it’s an asymmetrical key exchange. Iirc the server sends you a signed certificate and you need to unencrypt itnwithbtheir public key and sign it with your private key, so they can the getnit back and ensure that it was you who signed it, using your public key to check the validity of whatever was sent.
I don’t know enough to be 100% corrextbon the details, but the idea is that it’s an interaction between asymmetrical keys.
Soporta like how we use keysbto authenticate through github through SSL, but with an extra level of security where the server validates a key in a single endpoint, not wherever that private key would be held (like with SSL)
How is that different from mutual TLS authentication?
Edit: It seems like OPAQUE just initiates mutual TLS authentication after the TLS session has already been negotiated with PKI. So it basically just allows websites to design their own login page instead of the one designed by the web browser.
It’s like the initial authentication, where server and clientnexchange a symmetrical key with their asymmetrical keys. The difference is that in that exchange the server and the client meet for the first time whereas the point of pass keys is that once when you were already authenticated, you validated the device or whatever will hold the private key as a valid source, so then when the authentication code gets exchanged, both ends can verify that the other end is who they tell is, and both can verify the other end as valid, and thus that exchange authenticates you because you, in the past, while authenticated, trusted that device as valid.
Technically, yeah, it’s an asymmetrical key exchange. Iirc the server sends you a signed certificate and you need to unencrypt itnwithbtheir public key and sign it with your private key, so they can the getnit back and ensure that it was you who signed it, using your public key to check the validity of whatever was sent.
I don’t know enough to be 100% corrextbon the details, but the idea is that it’s an interaction between asymmetrical keys.
Soporta like how we use keysbto authenticate through github through SSL, but with an extra level of security where the server validates a key in a single endpoint, not wherever that private key would be held (like with SSL)