There's a fundamental problem with client certs as currently implemented in browsers as well as the <keygen> tag: these certificates aren't origin-bound and vio

There's a fundamental problem with client certs as currently implemented in browsers as well as the <keygen> tag: these certificates aren't origin-bound and violate the same-origin policy. The method of authorizing client certs without using the same-origin policy is the source of the horrible UX problems: ask the user (often without a "remember this choice" checkbox, so users were asked every session)! Determining which certificate to use can be difficult depending on the subject/issuer, and in general this is a terrible choice to ask a user to make. The problem gets a lot easier if you use origin-bound certificates: http://www.browserauth.net/origin-bound-certificates http://www.browserauth.net/origin-bound-certificates With origin-bound certs there's a clear and unambiguous answer as to what cert to use for a given origin by-design. These certs can either be dynamically provisioned in a browser or device-locked to e.g. a Yubikey U2F token. There's no need to ask the user anything more than to push the button on their hardware token if they have one. Otherwise the process is completely automatic. I really don't think efforts to use in-browser client cert authentication that don't respect the same-origin policy are going to get anywhere because of this problem.