Re: [webauthn] Individual Certificate Authority for credential management and recovery (#1844)

> > > they could generate a new keypair that has a signature chained to their personal certificate authority.
> 
> > How would an average end user manage a "personal certificate authority"? Most users don't even use a password manager.
> 
> Similar arguments were used against things like TLS on the majority of websites. That's a technology for banks! Most users also don't use USB 2-factor devices, yet clearly there's desire to support that within the standard. If we argue against innovation based on history or popularity we make little progress.

We aren't talking about banks or your company. We are talking about people. People like single mothers, or veterinarians, accountants, people who may be disabled in some way. 

These people are unlikely to have the operational knowledge or experience to run a certificate authority - let alone the time to maintain, backup and protect their own CA. This is not to say they are stupid, but that running a CA is hard, and most people in tech can't even do it correctly. How do we expect people outside of tech circles to do it correctly, if we can't? 

> That said, I think password manager use has grown with time. I think the logical conclusion of a password manager is to eventually became a store of keys. These keys may start out as random strings for filling out web forms, but grow to include WebAuthN credentials. 

And password managers are growing to support webauthn credentials. See dashlane for example. 

I'm not really sure what you are asking for her to be honest, because this is already solved in multiple ways (password managers support webauthn credentials, apple/google accounts with roaming authenticators, people with security keys, etc). 

We don't need people to be able to run their own CA's.

-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1844#issuecomment-1405919273 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 27 January 2023 01:53:18 UTC