
Perhaps it'll be useful for someone, but best to understand it as fragments of a better document that I'm accumulating.Īn authenticator is a map from ( RP ID, user ID) pairs, to public key credentials.

The next paragraph just drops you into things without a lot of context. I'll probably build on this in some future posts and maybe amalgamate some past writings into a single document. These are not new if you're fully versed in WebAuthn, but they are new if you've only used WebAuthn in a 2nd-factor context. What I wanted to cover in this post is the groundwork semantics around passkeys.
CRYPTOCAT STOPPED WORKING ON WINDOWS 7 HOW TO
The WebAuthn spec is not a gentle introduction, but you can find several guides on how to make the API calls. (* albeit not with Android this year, because it doesn't support a recent enough version of CTAP yet. Basing things on WebAuthn also means that you can still use your security key if you like *, and hopefully with a expanded ranges of sites. This could have been a different API, but it would have been a lot to have a second web API for public-key authentication, so WebAuthn it is. So the model for consumers replaces security keys with phones, and swaps out having a backup authenticator with backing up the private keys themselves. But we were not going to see broad adoption while the model was that you had to purchase a pair of security keys, be sure to register the backup on every site, yet also keep it in a fire safe.

WebAuthn has been working reasonably well for enterprises and technically adept users. The presentations are out now ( Google I/O, WWDC): we're making a push to take WebAuthn to the masses.
