4 ms·

Thanks for the informative response. Can you express in some more detail the user agent problem we have?

by jdc 10y ago

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 ago
  Okay 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!).

Thanks for the informative response. Can you express in some more detail the user agent problem we have?

by jdc 10y ago

Thanks for the informative response. Can you express in some more detail the user agent problem we have?

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 ago
Okay 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!).