On 7/5/23 08:47, Keith Moore wrote:
I guess I think that the authentication standards should be agnostic about what kind of authentication is used, that should be up to the service requiring authentication to decide. But every protocol should have at least one robust authentication method available that can be implemented purely in software and without using anything proprietary. (If a service wants to require some sort of proprietary frob to authenticate to that service, I guess that's up to them, but the standards should facilitate secure authentication between any two cooperating parties.)I think the best way is to expose a basic interface just for digital signatures via public key crypto, which is ultimately what WebAuthn kinda boils down to. But there should be no restrictions on the kind of device needed for authentication, e.g. some proprietary fob or Google / Apple's "trusted stores". Ultimately if it's running in a browser, on the client I have the choice to do whatever I want anyway (e.g. if I recompile Chromium with my WebAuthn shim that uses GnuPG for instance -not sure if it is possible in pure userland-JS right now).Keith
The choice should be exposed to the user at a top level, so there's no lock in. If I manage my keys poorly, that's my fault. But it should be MY choice. The service should not be providing the "type of key" (e.g. hardware backed) when they request me to authenticate, since that could be mocked / faked anyway. If it's something like a bank which really is anal about it, then they could provide their own hardware token to me, preloaded with the private key for which they've registered the corresponding public key. (That way I don't have access to the private key, so I can't mock it via some other keystore).
Otherwise, all the client side stuff forcing me to use certain tokens is just a facade, IMO.
Regards, Raghu
Attachment:
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
