Fix typos and spelling errors

content/Developer_Program/Guides/User_Loaded_Data.adoc

@@ -87,7 +87,7 @@ The generated responses consist of a 40 character hexadecimal string generated a
 The Static Password configuration will accept data in the following formats and lengths:
 Password - A string of up to 38 characters as defined by the keyboard scan code ID.
 
-The generated Static Password codes contain the characters as programed, provided that the host system is using the same keyboard layout as the system the password was programmed on.
+The generated Static Password codes contain the characters as programmed, provided that the host system is using the same keyboard layout as the system the password was programmed on.
 
 
 === OATH Application

content/Developer_Program/WebAuthn_Starter_Kit/Attestation.adoc

@@ -53,7 +53,7 @@ image::Images/attest-figure3.png[align="center"]
 
 The first of which is an "`allow list"`, whereby only a limited and pre-defined subset of all security devices may be registered and used as an authenticator in conjunction with a particular service. Depending on policies and how broad the array of security devices is amongst the userbase, this may be the most secure option to weed out potential issues created by untrusted security devices. One such example might be a strict requirement for a U.S. Federal agency mandated by Federal Information Processing Standards (FIPS) in order to protect sensitive or valuable data. Furthermore, allowed FIDO authenticators are usually those that have been tested internally or during development and have been vetted as a secure and compatible option.
 
-The second use case, which is similar to the first, is a "`deny list"`, which pre-emptively blocks a subset of all security devices instead. The benefit or advantage of this approach compared to the first is its more inclusive stance to security devices across the userbase but conversely, the major disadvantage is that it allows untrusted devices to be registered as well. Proponents of this approach aim to avoid alienating or preventing users from registering for the service and intend to only explicitly deny devices that have been flagged or outed as insecure alternatives.
+The second use case, which is similar to the first, is a "`deny list"`, which preemptively blocks a subset of all security devices instead. The benefit or advantage of this approach compared to the first is its more inclusive stance to security devices across the userbase but conversely, the major disadvantage is that it allows untrusted devices to be registered as well. Proponents of this approach aim to avoid alienating or preventing users from registering for the service and intend to only explicitly deny devices that have been flagged or outed as insecure alternatives.
 
 The third and final use case discussed here is what can be generally referred to as "`security advisory"`. The intention is that neither an allow or deny list is implemented but information is merely gathered and stored for the purposes of analyzing the data. The information may, of course, still be used at a later time to either allow or deny specific security devices, but the primary goal is to collate data, suggest to users if there are any potential issues with their registered devices and have a mechanism in place that may lead to prudent action when required.
 

content/Developer_Program/WebAuthn_Starter_Kit/Back-end_System_Design.adoc

@@ -2,7 +2,7 @@
 
 === Detailed Back-End System Design Introduction
 
-The WebAuthn Server manages the creation, update, and deletion of WebAuthn credentials associated with Amazon Cognito User Pool Identities. The Server is comprised of Amazon Congito User Pool to provide the identity framework, a MySQL compatible serverless
+The WebAuthn Server manages the creation, update, and deletion of WebAuthn credentials associated with Amazon Cognito User Pool Identities. The Server is comprised of Amazon Cognito User Pool to provide the identity framework, a MySQL compatible serverless
 link:https://aws.amazon.com/rds/aurora/serverless/[Amazon Aurora Database] to store user and credential information, and 3 Lambda functions to support the Cognito Custom Authentication flow.
 
 ==== Cognito User Pool
@@ -614,7 +614,7 @@ Finally, DefineChallenge returns a success response and token approval to Cognit
 
 If an account has already been created, a user may add a FIDO2 Authenticator using a usernameless flow - that is, the user does not need to enter their username at login. The logic for registration and authentication are identical to the Adaptive Multi-Factor Authentication flow discussed above - the primary change is that the `username` field is replaced with `preferred_username`. During authentication, the `preferred_username` is passed from the WebAuthn authentication data sent by the authenticator, and passed to Cognito.
 
-Note that while Cognito does allow for the `preferred_username` to be modified, doing so will break any authenticators registered with a usernameless flow, as the value sent by the authenticator will not match the Cognitio user pool data. While the Yubico WebAuthn Starter kit does not allow for the `preferred_username` to be changed, other implementations may have this functionality.
+Note that while Cognito does allow for the `preferred_username` to be modified, doing so will break any authenticators registered with a usernameless flow, as the value sent by the authenticator will not match the Cognito user pool data. While the Yubico WebAuthn Starter kit does not allow for the `preferred_username` to be changed, other implementations may have this functionality.
 
 
 ==== API Gateway Component

content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Back-End_Deployment.adoc

@@ -8,7 +8,7 @@ This guide, however, describes how to *manually* deploy the WebAuthn Starter Kit
 
 === Prerequisites
 
-See the prerequisities section in the tutorial Automated WebAuthnKit deployment at AWS.
+See the prerequisites section in the tutorial Automated WebAuthnKit deployment at AWS.
 
 === Clone or download the GitHub project
 

content/Developer_Program/WebAuthn_Starter_Kit/Installation/Manual_Front-End-Deployment.adoc

@@ -9,7 +9,7 @@ This guide, however, describes how to *manually* deploy the WebAuthn Starter Kit
 
 === Prerequisites
 
-See the prerequisities section in the tutorial Automated WebAuthnKit deployment at AWS.
+See the prerequisites section in the tutorial Automated WebAuthnKit deployment at AWS.
 
 Before proceeding with deploying the WebAuthnKit frontend, make sure to perform the steps in the tutorial Manually deploy and troubleshoot WebAuthnKit backend at AWS.
 

content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_High_Level_Architecture_Overview.adoc

@@ -98,7 +98,7 @@ image::Images/arch2-registration-flow-v1.png[]
 image::Images/arch3-usernameless-registration-flow-v1.png[]
 *Figure 4 - Usernameless Registration Flow*
 
-AWS Cogntio only allows sign in via four attributes:
+AWS Cognito only allows sign in via four attributes:
 
  * username
 

content/Developer_Program/WebAuthn_Starter_Kit/WebAuthn_Registration_Flow.adoc

@@ -1,7 +1,7 @@
 
 == WebAuthn registration process overview
 
-=== Pre-requisities
+=== Prerequisites
 
 The WebAuthn registration process described in this section is first and foremost based on the registration specification in the
 link:https://www.w3.org/TR/webauthn/[W3C WebAuthn standard]. The WebAuthn registration process is equivalent to the WebAuthn Make Credentials procedure. All WebAuthn registration parameters, JSON objects, and generic WebAuthn flows are based on the W3C WebAuthn standard.
@@ -154,7 +154,7 @@ image::Images/reg9-add-extra-yubikey-users-account.v2.png[]
 
 At this stage, the security key with resident credentials for can be used for Usernameless authentication in to the same account.
 
-If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registed for the Usernameless flow.
+If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registered for the Usernameless flow.
 
 image::Images/reg10-one-security-key-usernameless-flow-v2.png[]
 *Figure 11 - Only one security key is configured for the Usernameless flow*
@@ -443,7 +443,7 @@ image::Images/reg30-add-extra-yubikey-users-account-v2.png[]
 
 At this stage, the security key with resident credentials for can be used for Usernameless authentication in to the same account.
 
-If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registed for the Usernameless flow.
+If the user needs to re-use the same security key for the Usernameless flow, it is necessary to first delete the originally registered security key. Then only one security key is registered for the Usernameless flow.
 
 image::Images/reg31-one-security-key-usernameless-flow-v2.png[]
 *Figure 33 - Only one security key is configured for the Usernameless flow*

content/Mobile/Concepts.adoc

@@ -85,7 +85,7 @@ The Configuration comprises key material and parameters for how a slot is used.
 Yubico OTP:: A One-Time Password algorithm developed by Yubico, typically using 44 characters, Modhex encoded.
 OATH-HOTP:: The event-based 6-8 digit OTP algorithm as specified in RFC-4226.
 Static password:: A static (non-changing) password.
-Challenge-Response:: A HMAC-SHA1 key for use with challenge-response protocols (programatically activated, can require touch).
+Challenge-Response:: A HMAC-SHA1 key for use with challenge-response protocols (programmatically activated, can require touch).
 
 When writing a configuration to a Slot, any previous configuration in that slot is overwritten. However, it is also possible to update an existing slot with new flags, which alters the parameters used for it. Whether a slot is updatable or not is itself defined by a flag, which must have been set during previous configuration for this command to work.
 

content/Mobile_Dev/WebAuthn/IOS/Improve_Mobile_User_Experience.adoc

@@ -128,7 +128,7 @@ Figure 6 shows a code sample that includes a method that when invoked uses the b
 const platformEnums = {
   ANDROID_BIOMETRICS: {
     id: "ANDROID_BIOMETRICS",
-    platName: "Andorid Biometrics",
+    platName: "Android Biometrics",
   },
   WINDOWS_HELLO: {
     id: "WINDOWS_HELLO",

content/OTP/Libraries/Creating_your_own_library.adoc

@@ -3,6 +3,6 @@ Did you not find what you were looking for? Considering writing your own library
 The Yubico OTP protocol is relatively straight-forward to implement and there is a lot
 of reference code in various languages. Here are some other useful resources:
 
- * link:https://demo.yubico.com[demo.yubico.com], to see what data is being sent/recieved when validating an OTP.
+ * link:https://demo.yubico.com[demo.yubico.com], to see what data is being sent/received when validating an OTP.
  * link:/yubikey-val/Getting_Started_Writing_Clients.html[Getting started writing clients]
  * link:/yubikey-val/Validation_Protocol_V2.0.html[Validation protocol specification]

content/OTP/OTPs_Explained.adoc

@@ -24,7 +24,7 @@ will allow the validation server to know which OTPs have already been used.
 
 image:otp_details.png[]
 
-The outputed OTP of the YubiKey OTP is provided in the Modhex characterset. The Modhex characterset uses characters common across the majority of latin alphabet QWERTY keyboard layouts, allowing for functionality regardless of the language set.
+The YubiKey OTP output is provided in the Modhex character set. The Modhex character set uses characters common across the majority of latin alphabet QWERTY keyboard layouts, allowing for functionality regardless of the language set.
 
 .Hex to Modhex Substitution
 [cols="2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2"]

content/OTP/Specifications/OTP_decryption_protocol.adoc

@@ -36,4 +36,4 @@ For example:
 
 The data matching .* will be a english error message in one line.
 
-Any other kind of response means a hard error occured.
+Any other kind of response means a hard error occurred.

content/OTP/Specifications/OTP_validation_protocol.adoc

@@ -131,7 +131,7 @@ as described above.
 === Response
 
 If the verification server has successfully processed your request
-(even if the reponse is not a successful verification), it will return
+(even if the response is not a successful verification), it will return
 an HTTP status of `200 OK` with a text/plain body.
 
 If you get a `4xx` or `5xx` response you should retry your request a

content/PGP/Attestation.adoc

@@ -12,7 +12,7 @@ The concept of attestation is to cryptographically certify that a certain asymme
 |===================
 |*Attestation Key*|Private signature key to sign the generated Attestation Statement (also called Attesting Key)
 |*Attestation Certificate*|X.509 certificate for the Attestation Key, used as template for Attestation Statement
-|*Attestated Key*|OpenPGP signature, decryption, or authentication key to attest was generated on device
+|*Attested Key*|OpenPGP signature, decryption, or authentication key to attest was generated on device
 |*Attestation Statement*|Generated X.509 certificate specifying the Attested Key details, signed by the Attestation Key
 |===================
 
@@ -75,8 +75,8 @@ Some features of the generated Attestation Statement:
 * Issuer will be the subject of the template Attestation Certificate
 * Dates will be copied from the template Attestation Certificate
 * Subject will be the string "YubiKey OPGP Attestation " with the attested slot appended ("SIG", "DEC", or "AUT")
-* If the attestion key is RSA the signature will be SHA256-PKCS#1v1.5
-* If the attestion key is EC the signature will be ECDSA-SHA256
+* If the attestation key is RSA the signature will be SHA256-PKCS#1v1.5
+* If the attestation key is EC the signature will be ECDSA-SHA256
 
 Extensions in the generated certificate:
 

content/PGP/Git_signing.adoc

@@ -124,7 +124,7 @@ Date:   Sat Feb 22 11:00:00 2014 +0200
     Fixed a small undocumented feature that made foo crash
 ....
 
-As before, GPG has to have the public key of the signer to successuflly verify the signature.
+As before, GPG has to have the public key of the signer to successfully verify the signature.
 
 The previous command assumes that the commit of interest was the very last one. To verify a generic commit replace `HEAD` with the commit ID (`552b36ec86790bfdac679ab23e6d61133ff0b383` in this case).
 
@@ -148,7 +148,7 @@ If the signatures can not be verified, the merge will be aborted.
 
 Similarly, the `-S` switch can be used to sign the commit resulting from a merge.
 
-Also, if you created _annotated_ tags, when you merge them Git will create a new commit for you. During this process it will also verify the invovled signatures and include the verification output in the comment of the commit message.
+Also, if you created _annotated_ tags, when you merge them Git will create a new commit for you. During this process it will also verify the involved signatures and include the verification output in the comment of the commit message.
 
 Since Git version 2.2.0 it is also possible to sign git _pushes_ by doing `git push --signed`. This is used to prove the intention the author had of pushing a specific set of commits and have them become the new tip of some branch.
 

content/PGP/Importing_keys.adoc

@@ -67,7 +67,7 @@ Should be the real name associated with this key.
 
   Email address:
 
-Should be the email adress associated with this key.
+Should be the email address associated with this key.
 
   Comment:
 

content/PGP/PGP_PIN_Change_Behavior.adoc

@@ -10,11 +10,11 @@ If a user enters their current PIN such that the full correct value has extra ch
 For example, consider the case where a user has their YubiKey's OpenPGP functionality to use PIN with the current value of `123456`, and they wish to change this to `abcdef`.
 
 . User connects to their GPG tool and runs the command `gpg --card-edit`
-. User enters the command `passwd` to initate a user PIN change
+. User enters the command `passwd` to initiate a user PIN change
 . When prompted for the current PIN, the user enters an incorrect PIN of `123456**7**`
 . When prompted for the new value for the PIN, the user enters `abcdef`
 
-In this case, the current value for the PIN will be accepted, even though it has an extra character `7` appended to it. The PIN will appear to be changed to the new value `abcdef`. However, attempting to use this new value for the PIN will fail with an incorrect PIN warning. In actuallity, the new value for the PIN will be `7abcdef`, with the extra characters provided for the current PIN being prefixed to the supplied value for the new PIN.
+In this case, the current value for the PIN will be accepted, even though it has an extra character `7` appended to it. The PIN will appear to be changed to the new value `abcdef`. However, attempting to use this new value for the PIN will fail with an incorrect PIN warning. In actuality, the new value for the PIN will be `7abcdef`, with the extra characters provided for the current PIN being prefixed to the supplied value for the new PIN.
 
 === Underlying Causes
 This behavior arises from the OpenPGP Card specification, which has an unfortunate ambiguity around the change PIN functionality.

content/PIV/Guides/Securing_SSH_with_OpenPGP_or_PIV.adoc

@@ -70,10 +70,10 @@ link:../../SSH/Securing_SSH_with_FIDO2.html[Securing SSH with FIDO2]
 
 * FIDO2 allows for the direct generation of keys within the YubiKey itself, removing the need for a PKI framework or other applications for the generation of keys. OpenSSH directly interfaces with the FIDO2 function on the YubiKey, allowing it to select the key algorithm, as well as generating both discoverable as well as non-discoverable credentials.
 
-* With the support for both discoverable and non-discoverable FIDO2 credentials, FIDO2 allows SSH options for both local, secured endpoints with expidated ease of uses in addition to public open endpoints where credentials should remain on the YubiKey.
+* With the support for both discoverable and non-discoverable FIDO2 credentials, FIDO2 allows SSH options for both local, secured endpoints with expedited ease of uses in addition to public open endpoints where credentials should remain on the YubiKey.
 
 ==== Drawbacks to FIDO2
 
 * Windows does not yet support FIDO2 on SSH as of the last update to this page.
 
-* FIDO2 is based around a decentalized deployment, with no central server issuing or revoking keys. Keys must be indivdually deleted to revoke access in the event of lost or stolen YubiKeys.
+* FIDO2 is based around a decentralized deployment, with no central server issuing or revoking keys. Keys must be individually deleted to revoke access in the event of lost or stolen YubiKeys.

content/PIV/Guides/Smart_card-only_authentication_on_macOS.adoc

@@ -55,7 +55,7 @@ The YubiKey is now required for all authentication tasks on the system.
 === Additional options
 
 Note that even though this guide uses self-signed certificates, any
-pair of certifcates stored in slot 9a and 9d may be used for pairing. To also verify that
+pair of certificates stored in slot 9a and 9d may be used for pairing. To also verify that
 the certificates used are trusted, configure the `checkCertificateTrust` option in the profile.
 
 The `tokenRemovalAction` may be added to the profile to automatically start the screensaver

content/SSH/Securing_SSH_with_FIDO2.adoc

@@ -150,7 +150,7 @@ In addition to a native SSH client, the Windows OpenSSH beta release also contai
 . The SSH identity files (id_ecdsa_sk and  id_ecdsa_sk.pub) must be available in `~/.ssh/`
 
 
-Once those prerequisities are met, the openSSH client inside the WSL environment can be used seamlessly with the YubiKey plugged into the Windows host.
+Once those prerequisites are met, the openSSH client inside the WSL environment can be used seamlessly with the YubiKey plugged into the Windows host.
 
 
 == Troubleshooting