Skip to content

Commit b31384c

Browse files
authored
Update README.md
updated infos
1 parent 991b381 commit b31384c

File tree

1 file changed

+24
-14
lines changed

1 file changed

+24
-14
lines changed

README.md

Lines changed: 24 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
# WebAuthn
66
*A simple PHP WebAuthn (FIDO2) server library*
77

8-
Goal of this project is to provide a small, lightweight, understandable library to protect logins with security keys like Yubico or Solo, fingerprint on Android or Windows Hello.
8+
Goal of this project is to provide a small, lightweight, understandable library to protect logins with passkeys, security keys like Yubico or Solo, fingerprint on Android or Windows Hello.
99

1010
## Manual
1111
See /_test for a simple usage of this library. Check [webauthn.lubu.ch](https://webauthn.lubu.ch) for a working example.
@@ -50,15 +50,22 @@ This library supports authenticators which are signed with a X.509 certificate o
5050
alert ok or fail <----------------'
5151

5252
## Attestation
53-
What's attestation? Normally, you just need to verify that a login comes from the same device like the device used on registration. For this usecase, you don't need any attestation. If you need more security, maybe when you know that for your company login everyone has a solokey, you can verify with direct attestation, that this device is really a solokey. Companys could even buy own authenticators signed with a company-own root certificate, then you can verify that a authenticator is one of your company.
53+
Typically, when someone logs in, you only need to confirm that they are using the same device they used during
54+
registration. In this scenario, you do not require any form of attestation.
55+
However, if you need additional security, such as when your company mandates the use of a Solokey for login,
56+
you can verify its authenticity through direct attestation. Companies may also purchase authenticators that
57+
are signed with their own root certificate, enabling them to validate that an authenticator is affiliated with
58+
their organization.
5459

5560
### no attestation
5661
just verify that the device is the same device used on registration.
5762
You can use 'none' attestation with this library if you only check 'none' as format.
5863
* this is propably what you want to use if you want simple 2FA login protection like github, facebook, google, etc.
5964

6065
### indirect attestation
61-
the browser may replace the AAGUID and attestation statement with a more privacy-friendly and/or more easily verifiable version of the same data (for example, by employing an anonymization CA). You can not validate against any root ca, if the browser uses a anonymization certificate.
66+
the browser may replace the AAGUID and attestation statement with a more privacy-friendly and/or more easily
67+
verifiable version of the same data (for example, by employing an anonymization CA).
68+
You can not validate against any root ca, if the browser uses a anonymization certificate.
6269
this library sets attestation to indirect, if you select multiple formats but don't provide any root ca.
6370
* hybrid soultion, clients may be discouraged by browser warnings but then you know what device they're using (statistics rulez!)
6471

@@ -73,16 +80,18 @@ client or client device. Such client-side storage requires a resident credential
7380
This is only supported by FIDO2 hardware, not by older U2F hardware.
7481

7582
### How does it work?
76-
With normal **server-side key** process, the user enters its username (and maybe password),
77-
then the server replys with a list of all public key credential identifier, which had been registered by the user.
78-
Then, the authenticator takes the first of the provided credential identifier, which has been issued by himself,
79-
and responses with a signature which can be validated with the public key provided on registration.
80-
With **client-side key** process, the user don't have to provide an username or password.
81-
The server don't send any identifier; rather, the authenticator is looking up in it's own memory,
82-
if there is a key saved for this relying party. If yes, he's responding the same way like he's doing if you provide a
83-
list of identifier, there is no difference in checking the registration.
84-
Resident Credential is supported by Windows 10 (Firefox, Chromium). Browser on old OS like Windows 7
85-
do a fallback to FIDO U2F, which doesn't support resident credential.
83+
In a typical **server-side key** process, the user provides their username (and sometimes password)
84+
and the server responds with a list of all the public key credential identifiers that the user has registered.
85+
The authenticator then selects the first credential identifier it issued and responds with a signature
86+
that can be verified using the public key registered during the registration process.
87+
88+
In a client-side key process, the user does not need to provide a username or password.
89+
Instead, the authenticator searches its own memory to see if it has saved a key for the relying party.
90+
If a key is found, the authentication process proceeds in the same way as it would if the server had sent a list
91+
of identifiers. There is no difference in the verification process.
92+
93+
Both Apple and Windows 10/11 (with Firefox and Chromium) support Resident Credential.
94+
However, older operating systems such as Windows 7 do not support it and instead fall back to using FIDO U2F.
8695

8796
### How can I use it with this library?
8897
#### on registration
@@ -101,7 +110,7 @@ there is no difference to client-side discoverable credentials. The difference i
101110
syncing the credentials between the user’s devices via a cloud service. The cross-device sync of passkeys is managed transparently by the OS.
102111

103112
### Browser support
104-
Availability of built-in passkeys that automatically synchronize to all of a user’s devices:
113+
Availability of built-in passkeys that automatically synchronize to all of a user’s devices: (see also [passkeys.dev/device-support](https://passkeys.dev/device-support/))
105114
* Apple: iOS 16 / iPadOS 16 / macOS Ventura
106115
* Google: support in Android starting October 2022
107116
* Microsoft Windows is set to deliver support in 2023.
@@ -117,6 +126,7 @@ Availability of built-in passkeys that automatically synchronize to all of a use
117126
* [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
118127
* [dev.yubico](https://developers.yubico.com/FIDO2/)
119128
* [FIDO Alliance](https://fidoalliance.org)
129+
* [passkeys](https://passkeys.dev/)
120130

121131
## FIDO2 Hardware
122132
* [Yubico](https://www.yubico.com)

0 commit comments

Comments
 (0)