Re: [webauthn] What's this SPEC for?

Almost, but there are some important differences. Web Authentication does not assume that the user has a universal identity that they use for all websites, instead a new identity (_credential_) is created for each website. The purpose of this spec is

- to provide websites with a widely available API to authenticate users with strong asymmetric cryptography.
- to provide users with a solution to be much more secure with less effort. They don't need to remember any passwords. Instead they can use a single hardware key (_authenticator_) to securely log in everywhere, but without the risk that hackers could steal the key on one site and use it on another.

The following is a bit simplified, but describes the most important parts.

First, the user creates a new account or registers a new _credential_ (public-private key pair) to an existing account on the website:

1. User has an authenticator that can create and store credentials (private keys). An authenticator could be a software program, a TPM (trusted platform module) built into a computer/phone etc, an external USB/Bluetooth/NFC device on their keychain, or a future invention.
2. User visits a website and goes to register a new credential for their account.
3. Website sends a random _challenge_, a random _user ID_ (not username) and a (possibly empty) list of public keys the user has already registered.
4. User selects an authenticator that does not contain one of the already registered credentials.
5. That authenticator creates a new credential, stores the website domain and user ID with the credential and _signs_ the challenge, the public key and the website domain with an _attestation private key_.
6. User agent sends the signature, the public key and the _attestation certificate_ back to the website.
7. Website verifies the signature over the challenge and public key.
8. Website optionally inspects the attestation certificate and decides if it wants to trust the authenticator. The attestation certificate encodes information about the security properties of the authenticator, so a bank might for example choose to only trust TPMs and external hardware authenticators, and not software authenticators or unknown ones.
9. If the website decides to trust the authenticator (or doesn't care about the authenticator type), it registers the credential's public key with the user's account.

The next time the user visits this site:

1. User enters their username and password.
2. Website sends a random challenge and a list of public keys the user has registered.
3. User plugs in an authenticator if necessary, then selects one of the credentials in the list.
4. The authenticator that contains the selected credential signs the challenge and the website domain using the credential's private key.
5. User agent sends the signature and public key back the the website.
6. Website verifies that the public key is registered to the user, verifies the signature and then logs the user in as the given username.

This is the "second factor" use case. Alternatively, some authenticators and websites support a "first factor" use case making it possible to log in without even a username:

1. User requests to log in.
2. Website sends a random challenge.
3. User selects any credential bound to the website.
4. The authenticator containing the selected credential authenticates the user, for example using PIN or fingerprint.
5. Authenticator signs the challenge and the website domain.
6. User agent sends the signature, public key and user ID back to the website.
7. Website verifies that the public key is registered to that user ID, verifies the signature and logs the user in as that user ID.

Does this answer some of your questions?

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

Received on Saturday, 24 February 2018 11:21:56 UTC