Merge pull request #82 from noman-land/fix-typo

fix(docs): thrust -> trust, and others

docs/authentication.md

@@ -166,4 +166,4 @@ Sadly, there are a few things you cannot do.
 
 The specification is complex, areas like UX are left to platform's discretion and browser vendors have their own quirks. As such, I would highly recommend one thing: **test it out with a variety of browsers/platforms**. It's far from a consitent experience.
 
-Moreover, otpions like `hints`, `allowCredentials`, `userVerification` and `discoverable` may interact with each other and provide different UX depending on their combination and the time of the year. The protocol evolved dramatically in the last years, with changes to the UX every couple of months.
+Moreover, options like `hints`, `allowCredentials`, `userVerification` and `discoverable` may interact with each other and provide different UX depending on their combination and the time of the year. The protocol evolved dramatically in the last years, with changes to the UX every couple of months.

docs/faq.md

@@ -61,14 +61,14 @@ Not by default. Passkeys are a single step 2FA only if:
 
 When using synced "multi-device" passkeys, the "cloud" has the key, your devices have the key, and the key is in-transit over the wire. While vendors go to great length to secure every aspect, it is still exposed to more risk. All security guarantees are hereby delegated to the software authenticator, whether it's built-in in the platform or a password manager. At best, these passkeys are as safe as the main account itself. If the account is hacked, whether it's by a stolen password, temporary access to your device or a lax recovery procedure, all the passkeys would come along with the hacked account. While it offers convenience, the security guarantees are not as strong as with hardware bound authenticators.
 
-The privacy concerns are similar. It is a matter of thrust with the vendor.
+The privacy concerns are similar. It is a matter of trust with the vendor.
 
 
 ## How to deal with recovery when using hardware-bound credentials?
 
 A device can be lost, broken, or stolen. You must deal with it. The most straightforward way is to offer the user a way to register multiple passkeys, so that losing one device does not imply locking oneself out.
 
-Another alternative is to provide a recovery procedure per SMS or some other thrusted means.
+Another alternative is to provide a recovery procedure per SMS or some other trusted means.
 Relying on solely a password as recovery is discouraged, since the recovery per password then becomes the "weakest link" of the authentication system.
 
 

docs/registration.md

@@ -102,7 +102,7 @@ Then simply send this object as JSON to the server.
 4️⃣ Verifying the registration on the server
 -------------------------------------------
 
-To verify it server side, call the `verifyRegistration(...)` function. While registration is basically "thrust on first use", some basic checks are necessary. The most important one is to check if it matches the expected `challenge` used when initiating the registration procedure, and if the `origin` is the expected one. 
+To verify it server side, call the `verifyRegistration(...)` function. While registration is basically "trust on first use", some basic checks are necessary. The most important one is to check if it matches the expected `challenge` used when initiating the registration procedure, and if the `origin` is the expected one.
 
 ```js
 import { server } from '@passwordless-id/webauthn' 
@@ -114,7 +114,7 @@ const expected = {
 const registrationParsed = await server.verifyRegistration(registration, expected)
 ```
 
-While this is the minial verification, further verifications are possilbe.
+While this is the minimal verification, further verifications are possible.
 
 | Verification options | Description |
 |-------|-------------|