Sure. The thread's origin refers to TLS. Like some others have said, this is a UI/UX issue, and the UI needs to exist in the browser/curl/httpclient, as that takes the role of the client in the TLS handshake. The existing UX for selecting -- and managing -- keys and certificates is bad, and the cognitive load of these to the user is high. We don't know what a good UI would looks like because no one has made one yet, but the competition is existing 2nd factors: hardware token generators, software token generators, confirmation emails, confirmation texts, etc.

I assume by Web API you meant some functionality hook exposed in the browser which the website/webapp can access, like WebRTC [1], or web workers and others [2][3].

The sort of API you entertain would be useful for application-level authentication, but from the perspective of the end-user, it would fulfill a similar purpose to password managers. Bootstrapping this identity to contain useful data is the biggest issue. There is a similar proposal by security researcher Steve Gibson called SQRL [4], which sends a site-specific public key to a website generated from a master key the app keeps. This scheme is pretty good but it's designed to mint uncorrelatable, anonymous identities, so you're not 'jdc' at HN and other places, but [RANDOM STRING] at HN, and [DIFFERENT RANDOM STRING] at some other site.

I am, however, curious how you'd envision a web app would hook into such an API, and what functionality it would offer.

[1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API [2] https://docs.webplatform.org/wiki/apis#List_of_all_APIs [3] https://developer.mozilla.org/en-US/docs/WebAPI [4] https://www.grc.com/sqrl/sqrl.htm