4 ms·
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 ta
by niftich 10y ago
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 https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
[2] https://docs.webplatform.org/wiki/apis#List_of_all_APIs https://docs.webplatform.org/wiki/apis#List_of_all_APIs
[3] https://developer.mozilla.org/en-US/docs/WebAPI https://developer.mozilla.org/en-US/docs/WebAPI
[4] https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- jdc 10y agoOkay that's plenty of background info. So why not expose something like p12U_ImportPKCS12Object() to the web? You could generate and store the key and cert on the user's mobile device and have an app for pushing the cert via Bluetooth (which has a web api). Let the user and web server app sort out what his handle will be. It can be treated as a separate problem (however interesting it might be!).