This page (revision-3) was last changed on 29-Nov-2024 16:16 by -jim

This page was created on 29-Nov-2024 16:16 by unknown

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
3 29-Nov-2024 16:16 2 KB -jim to previous
2 29-Nov-2024 16:16 3 KB -jim to previous | to last
1 29-Nov-2024 16:16 1 KB unknown to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 2 changed 3 lines
[{$pagename}] is an [Authenticator] that follows the [WebAuthn Authenticator Model][{$pagename}] is a [device] that creates and stores user [credentials]. In a [password-based] authentication, the credentials (the [passwords]) are stored in the user's brain. In a [WebAuthN] scenario, the credentials are stored on a device. An authenticator can be a separate physical device, like a key fob connected to your computer via [USB], [Bluetooth], or [NFC]. It can also be embedded into the [Operating System], e.g., [Windows Hello], or into a [User-agent]. An authenticator can use interfaces to [fingerprint] readers or [facial recognition] sensors to confirm user credentials.
Previously, the only authenticators compatible with this specification were dedicated key fobs, which users had to acquire themselves. Such a solution was sufficient for the needs of corporations and security-savvy individuals.
[{$pagename}] is an [Authenticator] that follows the [WebAuthn Authenticator Model]
At line 6 removed one line
[FIDO2] compatible [{$pagename}] are built into [Operating System] and [Mobile Devices]. Thus, you can use your mobile phone as a [{$pagename}]. The phone will use security features available on the device to protect your credentials. This could be a PIN to unlock the phone, or data from the [fingerprint] reader. Most modern [Browsers] are now compatible with [WebAuthN] and offer built-in [{$pagename}]s that can communicate with the [Operating System] to authorize a user.
At line 8 changed one line
An important feature of an [{$pagename}] is that it connects with the client without using the [Internet] using the [Client To Authenticator Protocol]. You can use your [Mobile Device] as an [{$pagename}] to log in to a website opened on your laptop, but the phone has to connect to your computer via [Bluetooth Low Energy]. This prevents any [Man-In-The-Middle] attacks on the data exchanged between the [WebAuthn Client] and [{$pagename}]. Thanks to this, the [WebAuthn Client] can be sure it is really communicates with the [{$pagename}] and that the data has not been tampered with.
is an [Authenticator] and a [cryptographic] [entity] used by a [WebAuthn Client] to:
* generate a [Public Key] [credential] and register it with a [Relying Party]
* [authenticate] by potentially verifying the user, and then [cryptographically|Cryptography] [digitally signing|Digitally Signed] and returning, in the form of an [Authentication] [Assertion], and other [Data]
presented by a [WebAuthn Relying Party] in concert with the [WebAuthn Client].
At line 16 changed one line
* [Biometric Identification]Credential IDs are generated by [{$pagename}]s in two forms:
* [Biometric Identification]
Credential IDs are generated by [{$pagename}]s in two forms:
At line 18 changed one line
* The [Public Key] credential source, without its Credential ID, [encrypted] so only its managing [authenticator] can decrypt it. This form allows the [{$pagename}] to be nearly [stateless], by having the [WebAuthn Relying Party] store any necessary [state].[human-palatable]
* The [Public Key] credential source, without its Credential ID, [encrypted] so only its managing [authenticator] can decrypt it. This form allows the [{$pagename}] to be nearly [stateless], by having the [WebAuthn Relying Party] store any necessary [state].
At line 23 added 3 lines
[human-palatable]