The issue with client-side certificates is entirely the fault of the browser vendors. The user interface for browser-native authentication methods in general is terrible (modal dialogs in Firefox). The user interface for expired client certs is exactly the same as for expired server certs, so there is a large user support burden just from yearly expiring client certs. The W3C and browser vendors also dropped support for the <keygen> tag so users have to drop to the command-line to create new keys, which basically no-one except technical users can do. Also, since it removes control of the authentication flow from web designers, web developers and puts it in the hands of the web server and sysadmin, it is probably unpopular with the folks who control websites since users get subjected to substandard login UX. The new WebAuthn standard (that only works with JS IIRC) replaces client certs for the browser vendors, so it is likely client certs will be deprecated in the major browser vendors. https://bugzilla.mozilla.org/show_bug.cgi?id=1401466 https://github.com/w3c/html/issues/43 https://bugzilla.mozilla.org/show_bug.cgi?id=1315460 The Debian SSO uses client certs, but Debian are abandoning it for OAuth to the Debian GitLab instance. https://wiki.debian.org/DebianSingleSignOn https://lists.debian.org/msgid-search/20200418213339.GB32260@waldi.eu.org -- bye, pabs https://bonedaddy.net/pabs3/
The issues you mention don't affect the use-case I described, though. The end-user would never be expected to handle the certificates, just the service provider and the API client.
On Fri, 2020-06-12 at 21:24 -0400, Drew DeVault wrote: > The issues you mention don't affect the use-case I described, though. > The end-user would never be expected to handle the certificates, just > the service provider and the API client. Sure, I wanted to answer the general question of why they are an unused technology that thus is likely to bitrot and disappear. -- bye, pabs https://bonedaddy.net/pabs3/