Fix typos/mistakes/wording/links in documentation/comments (#1152)

* Fix typos/mistakes/wording/links in documentation

* Revert changing "suboption" to "sub-option"

Change pre-existing use of "sub-option" to "suboption".

* Accept suggestions

.aspect/bazelrc/convenience.bazelrc

@@ -4,7 +4,7 @@ build --keep_going
 test  --keep_going
 
 # Output test errors to stderr so users don't have to `cat` or open test failure log files when test
-# fail. This makes the log noiser in exchange for reducing the time-to-feedback on test failures for
+# fail. This makes the log noisier in exchange for reducing the time-to-feedback on test failures for
 # users.
 # Docs: https://bazel.build/docs/user-manual#test-output
 test --test_output=errors

.github/CONTRIBUTING.md

@@ -10,7 +10,7 @@ The following is a set of guidelines that we ask you to follow when you contribu
 * [Please Be Nice](#please-be-nice)
 * [Please Use Correct Medium (GitHub Issues / Discussions)](#please-use-correct-medium-github-issues--discussions)
 * [Please Include (Pseudo)code for Any Technical Issues](#please-include-pseudocode-for-any-technical-issues)
-* [Reviewer/Reviewee Guidelines](#reviewer-reviewee-guidelines)
+* [Reviewer/Reviewee Guidelines](#reviewerreviewee-guidelines)
 * [Brown M&M Clause](#brown-mm-clause)
 * [Pull Requests](#pull-requests)
   * [Branches](#branches)

.github/workflows/stale.yml

@@ -12,7 +12,7 @@ jobs:
           stale-issue-message: 'This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
           stale-pr-message: 'This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.'
           close-issue-message: 'This issue was closed because it has been stalled for 7 days with no activity. This does not mean your issue is rejected, but rather it is done to hide it from the view of the maintains for the time being. Feel free to reopen if you have new comments'
-          close-pr-message: 'This PR was closed because it has been stalled for 14 days with no activity. This does not mean your PR is rejected, but rather it is done to hide it from the view of the maintainers for the time being. Feel free to reopen if you have new comments or chnages that you would like to include. '
+          close-pr-message: 'This PR was closed because it has been stalled for 14 days with no activity. This does not mean your PR is rejected, but rather it is done to hide it from the view of the maintainers for the time being. Feel free to reopen if you have new comments or changes that you would like to include. '
           days-before-issue-stale: 14
           days-before-pr-stale: 14
           days-before-issue-close: 7

Changes

@@ -19,13 +19,13 @@ v2.1.0 18 Jun 2024
 
       # previously
       jwt.ParseRequest(req) // looks under Authorization
-      jwt.ParseReuqest(req, jwt.WithFormKey("foo")) // looks under foo AND Authorization
-      jwt.ParseReuqest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization
+      jwt.ParseRequest(req, jwt.WithFormKey("foo")) // looks under foo AND Authorization
+      jwt.ParseRequest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization
 
       # since this release
       jwt.ParseRequest(req) // same as before
       jwt.ParseRequest(req, jwt.WithFormKey("foo")) // looks under foo
-      jwt.ParseReuqest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization
+      jwt.ParseRequest(req, jwt.WithHeaderKey("Authorization"), jwt.WithFormKey("foo")) // looks under foo AND Authorization
 
   * [jwt] Add `jwt.WithResetValidators()` option to `jwt.Validate()`. This option
     will allow you to tell `jwt.Validate()` to NOT automatically check the
@@ -43,13 +43,13 @@ v2.1.0 18 Jun 2024
     `jwx_es256k` to enable ES256K/secp256k1, and `jwx_secp256k1_pem` to enable PEM handling.
     Not one, but BOTH tags need to be present.
 
-    With this change, by suppliying the `WithPEM(true)` option, `jwk.Parse()` is now
+    With this change, by supplying the `WithPEM(true)` option, `jwk.Parse()` is now
     able to read sep256k1 keys. Also, `jwk.Pem()` should be able to handle `jwk.Key` objects
     that represent a secp256k1 key.
 
     Please do note that the implementation of this feature is dodgy at best. Currently
     Go's crypto/x509 does not allow handling additional EC curves, and thus in order to
-    accomodate secp256k1 keys in PEM/ASN.1 DER format we need to "patch" the stdlib.
+    accommodate secp256k1 keys in PEM/ASN.1 DER format we need to "patch" the stdlib.
     We do this by copy-and-pasting relevant parts of go 1.22.2's crypto/x509 code and
     adding the minimum required code to make secp256k1 keys work.
 
@@ -106,7 +106,7 @@ v2.0.20 20 Feb 2024
     JWS message.
   * [jwt] Add `jwt.WithCompactOnly()` to specify that only compact serialization can
     be used for `jwt.Parse()`. Previously, by virtue of `jws.Parse()` allowing either
-    JSON or Compact serialization format, `jwt.Parse()` also alloed JSON serialization
+    JSON or Compact serialization format, `jwt.Parse()` also allowed JSON serialization
     where as RFC7519 explicitly states that only compact serialization should be
     used. For backward compatibility the default behavior is not changed, but you
     can set this global option for jwt: `jwt.Settings(jwt.WithCompactOnly(true))`
@@ -125,7 +125,7 @@ v2.0.19 09 Jan 2024
 [Security Fixes]
   * [jws] JWS messages formated in full JSON format (i.e. not the compact format, which
     consists of three base64 strings concatenated with a '.') with missing "protected"
-    headers could cause a panic, thereby introducing a possiblity of a DoS.
+    headers could cause a panic, thereby introducing a possibility of a DoS.
 
     This has been fixed so that the `jws.Parse` function succeeds in parsing a JWS message
     lacking a protected header. Calling `jws.Verify` on this same JWS message will result
@@ -219,7 +219,7 @@ v2.0.14 17 Oct 2023
     asymmetric key pair.
 [Security]
   * golang.org/x/crypto has been updated to 0.14.0. The update contains a fix for HTTP/2
-    rapid reset DoS vulnerability, which some security scanning softwares may flag.
+    rapid reset DoS vulnerability, which some security scanning software may flag.
     However, do note that this library is NOT affected by the issue, as it does not have
     the capability to serve as an HTTP/2 server. This is included in this release
     document so that users will be able to tell why this library may be flagged
@@ -261,7 +261,7 @@ v2.0.10 - 12 Jun 2023
 
     This feature is labeled experimental because the API for the above interfaces have not
     been battle tested, and may need to changed yet. Please be aware that until the API
-    is deemed stable, you may have to adapat our code to these possible changes,
+    is deemed stable, you may have to adapt your code to these possible changes,
     _even_ during minor version upgrades of this library.
 
 [Bug fixes]
@@ -283,7 +283,7 @@ v2.0.10 - 12 Jun 2023
     If you care about this performance improvement, you should probably enable
     `goccy` JSON parser as well, by specifying `jwx_goccy,jwx_asmbase64` in your build call.
   * Slightly changed the way global variables underneath `jwk.Fetch` are initialized and
-    configured. `jwk.Fetch` creates an object that spawns wokers to fetch JWKS when it's
+    configured. `jwk.Fetch` creates an object that spawns workers to fetch JWKS when it's
     first called.
     You can now also use `jwk.SetGlobalFetcher()` to set a fetcher object which you can
     control.
@@ -304,7 +304,7 @@ v2.0.9 - 21 Mar 2023
     Note that there is no way to call
     `jws.Verify()` while allowing `{"alg":"none"}` as you wouldn't be _verifying_
     the message if we allowed the "none" algorithm. `jws.Parse()` will parse such
-    messages witout verification.
+    messages without verification.
 
     `jwt` also allows you to sign using alg="none", but there's no symmetrical
     way to verify such messages.
@@ -373,7 +373,7 @@ v2.0.7 - 15 Nov 2022
 
 [Miscellaneous]
   * WithCompact's stringification should have been that of the
-    internal indentity struct ("WithSerialization"), but it was
+    internal identity struct ("WithSerialization"), but it was
     wrongly producing "WithCompact". This has been fixed.
   * Go Workspaces have been enabled within this module.
     - When developing, modules will refer to the main jwx module that they
@@ -410,7 +410,7 @@ v2.0.5 - 11 Aug 2022
 v2.0.4 - 19 Jul 2022
 [Bug Fixes]
   * [jwk] github.com/lestrrat-go/httprc, which jwk.Cache depends on,
-    had a problem with inserting URLs to be re-fetched into its queue.
+    had a problem with inserting URLs to be refetched into its queue.
     As a result it could have been the case that some JWKS were not
     updated properly. Please upgrade if you use jwk.Cache.
 
@@ -419,20 +419,20 @@ v2.0.4 - 19 Jul 2022
   * [jwk] Fix doc buglet in `KeyType()` method
 
 [New Features]
-  * [jws] Add `jws.WithMultipleKeysPerKeyID()` sub-option to allow non-unique
+  * [jws] Add `jws.WithMultipleKeysPerKeyID()` suboption to allow non-unique
     key IDs in a given JWK set. By default we assume that a key ID is unique
     within a key set, but enabling this option allows you to handle JWK sets
     that contain multiple keys that contain the same key ID.
 
   * [jwt] Before v2.0.1, sub-second accuracy for time based fields
     (i.e. `iat`, `exp`, `nbf`) were not respected. Because of this the code
-    to evaluate this code had always truncated any-subsecond portion
+    to evaluate this code had always truncated any sub-second portion
     of these fields, and therefore no sub-second comparisons worked.
     A new option for validation `jwt.WithTruncation()` has been added
     to workaround this. This option controls the value used to truncate
     the time fields. When set to 0, sub-second comparison would be
     possible.
-    FIY, truncatation will still happen because we do not want to
+    FIY, truncation will still happen because we do not want to
     use the monotonic clocks when making comparisons. It's just that
     truncating using `0` as its argument effectively only strips out
     the monotonic clock
@@ -450,14 +450,14 @@ v2.0.2 - 23 May 2022
 
 [New Features]
   * [jwt] RFC3339 timestamps are also accepted for Numeric Date types in JWT tokens.
-    This allows users to parse servers that errnously use RFC3339 timestamps in
+    This allows users to parse servers that erroneously use RFC3339 timestamps in
     some pre-defined fields. You can change this behavior by setting 
     `jwt.WithNumericDateParsePedantic` to `false`
   * [jwt] `jwt.WithNumericDateParsePedantic` has been added. This is a global
     option that is set using `jwt.Settings`
 
 v2.0.1 - 06 May 2022
-  * [jwk] `jwk.Set` had erronously been documented as not returning an error
+  * [jwk] `jwk.Set` had erroneously been documented as not returning an error
     when the same key already exists in the set. This is a behavior change
     since v2, and it was missing in the docs (#730)
   * [jwt] `jwt.ErrMissingRequiredClaim` has been deprecated. Please use

Changes-v2.md

@@ -73,7 +73,7 @@ jws.Verify(signed, jws.WithKeySet(jwks), jws.WithKeyUsed(&keyUsed))
 
 ```go
 // basic
-jwe.Encrypt(payload, jwe.WithKey(alg, key)) // other defaults are infered
+jwe.Encrypt(payload, jwe.WithKey(alg, key)) // other defaults are inferred
 jwe.Encrypt(payload, jwe.WithKey(alg, key), jwe.WithKey(alg, key), jwe.WithJSON(true))
 jwe.Decrypt(encrypted, jwe.WithKey(alg, key))
 
@@ -92,7 +92,7 @@ jwe.Verify(signed, jwe.WithKeySet(jwks), jwe.WithKeyUsed(&keyUsed))
 
 * Module now requires go 1.16
 
-* Use of github.com/pkg/errors is no more. If you were relying on bevaior
+* Use of github.com/pkg/errors is no more. If you were relying on behavior
   that depends on the errors being an instance of github.com/pkg/errors
   then you need to change your code
 
@@ -243,8 +243,8 @@ jws.Verify(signed, jws.WithKeySet(cachedSet))
   but this has been removed. This is to avoid unwanted clogging of the fetch workers
   which is the default processing mode in `github.com/lestrrat-go/httprc`.
 
-  If you are using backoffs, you need to control your inputs more carefully so as to
-  not clog your fetch queue, and therefore you should be writing custom code that
+  If you are using backoffs, you need to control your inputs more carefully so as
+  not to clog your fetch queue, and therefore you should be writing custom code that
   suits your needs
 
 ## JWS
@@ -306,7 +306,7 @@ jws.Parse(serialized,
   The rest of the arguments are treated as options passed to the
   `(jwk.Fetcher).Fetch()` function.
 
-* Remove `jws.WithPayloadSigner()`. This should be completely repleceable
+* Remove `jws.WithPayloadSigner()`. This should be completely replaceable
   using `jws.WithKey()`
 
 * jws.WithKeyProvider() has been added to specify arbitrary

README.md

@@ -240,7 +240,7 @@ Please try [discussions](https://github.com/lestrrat-go/jwx/tree/v2/discussions)
 
 # Related Modules
 
-* [github.com/lestrrat-go/echo-middileware-jwx](https://github.com/lestrrat-go/echo-middleware-jwx) - Sample Echo middleware
+* [github.com/lestrrat-go/echo-middleware-jwx](https://github.com/lestrrat-go/echo-middleware-jwx) - Sample Echo middleware
 * [github.com/jwx-go/crypto-signer/gcp](https://github.com/jwx-go/crypto-signer/tree/main/gcp) - GCP KMS wrapper that implements [`crypto.Signer`](https://pkg.go.dev/crypto#Signer)
 * [github.com/jwx-go/crypto-signer/aws](https://github.com/jwx-go/crypto-signer/tree/main/aws) - AWS KMS wrapper that implements [`crypto.Signer`](https://pkg.go.dev/crypto#Signer)
 

cmd/jwx/jwe.go

@@ -39,7 +39,7 @@ func keyEncryptionFlag(required bool) cli.Flag {
 func makeJweEncryptCmd() *cli.Command {
 	var cmd cli.Command
 	cmd.Name = "encrypt"
-	cmd.Usage = "Encrypt payload to generage JWE message"
+	cmd.Usage = "Encrypt payload to generate JWE message"
 	cmd.UsageText = `jwx jwe encrypt [command options] FILE
 
    Encrypt contents of FILE and generate a JWE message using

cmd/jwx/jws.go

@@ -41,7 +41,7 @@ func makeJwsCmd() *cli.Command {
 func makeJwsParseCmd() *cli.Command {
 	var cmd cli.Command
 	cmd.Name = "parse"
-	cmd.Usage = "Parse JWS mesage"
+	cmd.Usage = "Parse JWS message"
 	cmd.UsageText = `jwx jws parse [command options] FILE
 
    Parse FILE and display information about a JWS message.
@@ -203,7 +203,7 @@ func makeJwsSignCmd() *cli.Command {
 	var cmd cli.Command
 	cmd.Name = "sign"
 	cmd.Aliases = []string{"sig"}
-	cmd.Usage = "Verify JWS mesage"
+	cmd.Usage = "Verify JWS message"
 	cmd.UsageText = `jwx jws sign [command options] FILE
 
    Signs the payload in FILE and generates a JWS message in compact format.

docs/00-anatomy.md

@@ -6,7 +6,7 @@ In this article we will briefly go over what JOSE is, and how each JWX libraries
 
 # JOSE Overview
 
-Javascript Object Signing and Encryption is mainly comprised of specifications that span over 5 RFCs: namely RFC7515, RFC7516, RFC7517, RFC7518, and RFC7519.
+Javascript Object Signing and Encryption mainly consists of specifications that span over 5 RFCs: namely RFC7515, RFC7516, RFC7517, RFC7518, and RFC7519.
 
 * [RFC 7515 - JSON Web Signature (JWS)](https://tools.ietf.org/html/rfc7515)
 * [RFC 7516 - JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516)
@@ -32,7 +32,7 @@ Most of the times this information must be integrity checked using signatures, s
 
 While they are referenced from RFC7519, the standardized message formats for signed and/or encrypted JWTs are not in the same RFC.
 
-As a side note, many libraries bundle these signature/encryption features into one JWT package, and API becomes tightly coupled with the JWT, which I find confusing and hard to fix/extend- which is part of the reason why JWX was born.
+As a side note, many libraries bundle these signature/encryption features into one JWT package, and the API becomes tightly coupled with the JWT, which I find confusing and hard to fix/extend which is part of the reason why JWX was born.
 
 ## Documentation for `github.com/lestrrat-go/jwx/v2/jwt`
 
@@ -56,7 +56,7 @@ Please note that a JWS message may take three forms: compact, full JSON, and fla
 graph TD
     RawData[Raw Data] --> |"three base64 encoded segments,<br/> concatenated with ."| Compact[Compact Serialization]
     RawData --> | JSON | JSON[JSON Serialization]
-    JSON --> |"does NOT have'signature'"| FullJSON[Full JSON Serialization]
+    JSON --> |"does NOT have 'signature'"| FullJSON[Full JSON Serialization]
     JSON --> |"has 'signature'"| Flat[Flattened JSON Serialization]
 ```
 
@@ -86,7 +86,7 @@ JWE is implemented in github.com/lestrrat-go/jwe package. This package provides
 
 # JWK - RFC7517
 
-So JWTs can be signed and/or encrypted using JWS and JWE. However in order to do either operation one needs some sort of a key. This is where RFC757 which describes JWK comes into play.
+So JWTs can be signed and/or encrypted using JWS and JWE. However, in order to do either operation one needs some sort of key. This is where RFC757 which describes JWK comes into play.
 
 JWKs describe formats to describe keys, such as RSA keys, Elliptic Curve keys, symmetric keys, etc. Each family of keys have a slightly different, unique format, but they are all encoded as JSON objects. 
 
@@ -110,6 +110,6 @@ JWK is implemented in github.com/lestrrat-go/jwx/v2/jwk package. This package pr
 
 # JWA - RFC7518
 
-And finally, RFC exists to define commonly used algorithm names in JWT, JWS, JWE, and JWK. 
+And finally, an RFC exists to define commonly used algorithm names in JWT, JWS, JWE, and JWK.
 
 This is implemented in github.com/lestrrat-go/jwx/v2/jwa.