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/