Isso é muito bom!
Uma pequena ressalva, porém: no Safari/Mac, a Autenticação Web é um recurso exclusivo para desenvolvedores, desativado por padrão. Quando ativado, funciona bem. Mas provavelmente deveríamos exibir uma mensagem ou um aviso quando a Autenticação Web não estiver habilitada. Atualmente, no Safari padrão, nada na interface indica que o processo de registro não funcionará (o console apresenta um erro):
Podemos detectar recursos usando navigator.credentials, imagino.
Algumas pessoas têm dificuldade em justificar o custo extra, mesmo que seja bom 
Argh, eu fiz essa verificação de recurso no navigator.credentials.get, mas não no create. Desculpe por isso, será uma correção rápida!
O commit mais recente parece estar funcionando. Consegui usar a autenticação de dois fatores (com impressão digital!) no meu celular Android agora mesmo.
Ei, Penar, tenho uma correção pronta para isso agora. Você consegue verificar no Safari? [FIX] Check webauthn support when registering security keys by mjrbrennan · Pull Request #8146 · discourse/discourse · GitHub . Só não tenho certeza se o método de detecção de recurso que estou usando vai funcionar no Safari com o recurso desativado.
O Sam foi mais rápido que eu na fusão, mas isso parece bom no Safari. Obrigado, Martin!
Certo, mas neste caso, trata-se de uma parte normal do trabalho no Discourse, então nós cobriríamos o custo. Desculpe se não ficou claro, mas espero que agora esteja.
Parabéns pelo suporte ao WebAuthn! É interessante ver que vocês criaram sua própria solução em vez de usar a gem webauthn. Se houver algum feedback para nós, adoraria ouvir
Percebi que na sua implementação apenas o algoritmo -7 (ES256) é suportado, mas os autenticadores de plataforma do Windows Hello (baseados em hardware TPM 2.0) exigem o -257 (RS256), conforme documentação da Microsoft. O TPM 2.0 é obrigatório desde 28 de julho de 2016 para novos modelos de desktop com Windows 10, o que representa uma quantidade significativa de hardware.
Uma sugestão para o mockup do “Fluxo de Login”: o WebAuthn possui um logotipo oficial que poderia ser usado no lugar de uma imagem genérica de impressão digital. Além da impressão digital, reconhecimento facial, padrão de deslize ou PIN também são opções comuns de verificação do usuário.
@Martin_Brennan alguma opinião sobre 
Obrigado pelo feedback, Rafe. Precisaremos adicionar o algoritmo adicional aqui então. E obrigado também pelo link para o logotipo oficial! Minha ideia ao definir apenas um algoritmo foi adicionar o número mínimo de algoritmos suportados para fazer tudo funcionar na V1, pois não estava certo das nuances entre todos os algoritmos, e o ES256 era usado em todos os exemplos que consegui encontrar.
Quanto ao motivo de, na época, eu ter optado por não usar a gem, pensei muito sobre isso e sabia que essa decisão seria questionada em algum momento. Certamente li bastante código da gem para entender melhor a implementação. As principais razões foram:
Dito isso, isso pode ter sido um equívoco da minha parte. Se chegarmos à V2, V3, etc., do suporte ao WebAuthn com atestações, mais algoritmos suportados e assim por diante, pode se tornar muito trabalhoso para nós nos tornarmos “especialistas em WebAuthn”, por assim dizer. Nesse ponto, acho que poderíamos reavaliar o uso da gem.
O suporte ao algoritmo adicional RS256 foi mesclado FEATURE: Support RS256 algorithm for webauthn by martin-brennan · Pull Request #8385 · discourse/discourse · GitHub
Parece que o iOS 13.3 e o macOS Catalina 10.15.2 agora também suportam FIDO2-auth 
Esta atualização também inclui correções de bugs e outras melhorias. Esta atualização:
- Adiciona suporte a chaves de segurança compatíveis com FIDO2 via NFC, USB e Lightning no Safari
É uma pena que os iPhones precisem de um dispositivo de terceiros para isso, no entanto. Espero que o iOS++ tenha isso integrado com autenticação do dispositivo e chip de segurança, como no Windows, Mac OS e Android.
Estou tão animado por fazer login no Discourse só de olhar para ele!!
Na verdade, estou meio surpreso de que o suporte a autenticador integrado ainda não esteja disponível… mas são notícias animadoras de qualquer forma — continuarei com a respiração suspensa.
Observou uma possível inconsistência na interface ao indicar a ativação da autenticação de dois fatores (2FA) para alguns usuários em uma instância hospedada do Discourse:
A listagem de todos os usuários ‘Staff’ não mostra minha conta como tendo o 2FA ativado:
A página de resumo da conta sugere que o 2FA está ativado, dado o texto do botão ‘Gerenciar Autenticação de Dois Fatores’.
A seção de Autenticação de Dois Fatores mostra que uma Chave de Segurança está ativada e que o Segundo Fator pode ser desativado.
Outros usuários na mesma instância que optam por usar um Autenticador Baseado em Token (sem Chave de Segurança) exibem o ícone de cadeado na listagem de ‘todos os usuários’.
Por favor, me avise se isso é um bug na interface ou se simplesmente adicionar uma Chave de Segurança não é suficiente para o 2FA nesta plataforma.
Vou dar uma olhada nisso, mas minha melhor suposição é que seja apenas um bug de interface na lista de usuários, caso a seção real de 2FA da interface esteja exibindo tudo corretamente. Obrigado pelo relato!
Esse era o problema. A correção está sendo construída aqui e eu a fundirei assim que puder FIX: Admin user list not showing 2FA icon for only security keys enabled by martin-brennan · Pull Request #8839 · discourse/discourse · GitHub
Edição: Isso já está corrigido.
Bem-vindo ao novo mundo corajoso
A Apple se juntou à FIDO Alliance (também conhecida como Fast Identity Online), uma organização que já inclui gigantes como Google, Intel, Microsoft e Samsung.
Isso funciona usando TouchID / FaceID no iOS 14.
