Re: [webauthn] Is there a community for webauthn implementation discussion?

As someone who has been working with PKI for two decades, its 
frustrating to watch people new to FIDO reinventing problems that made 
PKI unacceptable for consumers (and extraordinarily expensive for 
businesses and government use-cases). Time and again, I notice FIDO 
marching down the same path as PKI; account recovery is another area 
where the same issue has resurfaced.

This problem is not a new problem.  It has been debated, discussed and 
hashed many times over; and companies/agencies have learned that in the 
end, it boils down to the need for security or convenience - you cannot 
have both.

The last 20 years of web-computing have shown what convenience has 
wrought: thousands of known breaches with billions of user records 
compromised (  It doesn't 
matter what you use: OTP, TOTP, SMS, KYC, blah... any authentication 
scheme based on a shared secret almost certainly leads to a scalable 
attack and compromise.

The tendency of some of the largest companies in the world to treat 
their users as idiots is at the root of this problem.  However, if you 
stop to think about it, humans have managed pretty well over the years 
dealing with the complexity of self-service machines: vending machines, 
gas-pumps, ATMs, blood-pressure testing machines, ticketing machines and 
now grocery checkout machines and even immigration counters.  Humans can 
be trained to deal with complexity if we choose to address it as an 

IMO, the PKI industry did not solve the account recovery problem 
(cost-effectively), and it is unlikely the FIDO industry will do it 
either.  It is far easier to educate users to register two separate 
Authenticators to their account and lock one up for safekeeping, to be 
used to recover their accounts.

This is also an opportunity for Authenticator manufacturers to partner 
with smartphone/tablet/laptop manufacturers and bundle a USB/NFC/BLE 
Authenticator with each new FIDO-enabled platform device, and for 
Relying Parties (RPs) to have a registration flow that prompts - and 
repeatedly encourages/reminds - users to register their backup 
Authenticator when they register their first key and have not registered 
a second key.

With the inclusion of extensions and the RSA algorithm in 
FIDO2/WebAuthn, things have gotten muddied enough as it is.  Lets not 
kill this goose with complexity before its starts delivering its golden 
eggs - you only have to learn the history of consumer-focused PKI to 
understand why it failed.

Arshad Noor

On 10/28/2018 07:12 AM, Jonathan Underwood via GitHub wrote:
>> That seems outside the scope of WebAuthn.
> While I agree that the WebAuthn spec should not require anything in 
> regards to key loss, I think that a place to discuss implementation 
> details like this is useful to increasing adoption.
> Nothing prevents me from implementing it. But your assumption tells me 
> you agree that adding a reset code feature is recommended? I am 
> impartial to the idea, and am just open to new ideas from other 
> implementations... maybe someone thought of new implications that 
> WebAuthn introduces (considering the fact that it is much broader than 
> the current "norms" of 2FA which is restricted usually to a TOTP based 
> app on a smartphone in most implementations).
> ie. UX design around auth will now have to account for "this could be 
> biometrics tied to a device" or "this could be a USB key with NFC on it 
> so it can be used with multiple devices."... So if you activate 
> password-less login and disable password login, and the only device 
> registered is a Yubikey, you can login with any device that accepts 
> input from a Yubikey, but if it's an iPhone TouchID, then that user can 
> only login with one device now... unless we add some way to have the 
> WebAuthn auth from the iPhone allow the user to login on another device 
> through push notifications and native apps on our backend etc.
> When designing an auth system using WebAuthn... it feels like 99% of 
> people look at it as a drop in replacement for passwords|TOTP|SMS 
> whatever it may be... but after talking to our designers and UX guys 
> after reading into the spec, it's a lot more complicated than that IMO.
> Again, to bring things back in for a moment: Is there a place where 
> people who are implementing are gathering that I might be able to 
> lurk/participate in?

Received on Tuesday, 30 October 2018 08:16:44 UTC