Merge pull request #142 from vladdoster/main

docs: fix spelling

Author: iinuwa

ARCHITECTURE.md

@@ -13,7 +13,7 @@ two services that implement the three APIs defined by the specification:
 These two services communicate with each other over D-Bus IPC.
 
 The **Gateway** is the entrypoint for clients to interact with. The Flow
-Controler and UI Controller work together to guide the user through the
+Controller and UI Controller work together to guide the user through the
 process of selecting an appropriate credential based on the request received by
 the Gateway.
 
@@ -140,7 +140,7 @@ few tests there; this should be expanded in the future.
 
 Rust types shared between `credentialsd` and `credentials-ui`.
 
-Most of the types live in `src/model.rs`, and some are duplciated in
+Most of the types live in `src/model.rs`, and some are duplicated in
 `src/server.rs`. The duplicates in the `server` module have tweaks that make it
 easier to serialize over D-Bus, but more difficult to work with in Rust. So
 conversion methods are provided between the two modules.
@@ -163,7 +163,7 @@ the fact that it uses async-std, and some frameworks may prefer Tokio or another
 async runtime.) This is intended to aid other GUI developers using other
 frameworks to set up their projects. For a given framework, it may be more
 intuitive not to have this separation or to structure the code differently, but
-the separation fo concerns here makes it clear what the developer needs to do.
+the separation of concerns here makes it clear what the developer needs to do.
 
 ### `credentialsd-ui/src/view_model/gtk/`
 

CONTRIBUTING.md

@@ -149,7 +149,7 @@ use super::MyType;
 
 ### Commit Messages
 
-The commit message should start with the _area_ that is affected by the change, which is usually the name of the folder withouth the `credentialsd-` prefix. The exception is `credentialsd/` itself, which should use `daemon`.
+The commit message should start with the _area_ that is affected by the change, which is usually the name of the folder without the `credentialsd-` prefix. The exception is `credentialsd/` itself, which should use `daemon`.
 
 Write commit messages using the imperative mood, as if completing the sentence:
 "If applied, this commit will \_\_\_." For example, use "Fix some bug" instead

SECURITY.md

@@ -46,7 +46,7 @@ of this scope, we still want to know about it! We would still like to discuss
 the issue privately, but we may decide to address it beyond the response
 time described above.
 
-## Definitons
+## Definitions
 
 - _privileged client_: A client that is allowed to make requests for credentials
   for any origin.

doc/api.md

@@ -7,7 +7,7 @@ There are three main API defined by this specification:
 - [UI Control API](#ui-control-api)
 
 The **Gateway** is the entrypoint for clients to interact with. The Flow
-Controler and UI Controller work together to guide the user through the
+Controller and UI Controller work together to guide the user through the
 process of selecting an appropriate credential based on the request received by
 the Gateway.
 
@@ -70,7 +70,7 @@ sequenceDiagram
 - _credential_: a value that identifies a user to a relying party
 - _gateway_: entrypoint for clients
 - _privileged_ client: a client that is trusted to set any origin for its requests
-- _relying party_: an entity wishing to auhtenticate a user
+- _relying party_: an entity wishing to authenticate a user
 - _unprivileged client_: a client that is constrained to use a predetermined set of origin(s)
 
 # General Notes
@@ -812,7 +812,7 @@ A method to send a client PIN to an authenticator in response to a `UsbState::NE
 
 ### Request
 
-`pin`: Client PIN for the authenticaor.
+`pin`: Client PIN for the authenticator.
 
 This should be sent in response to a `UsbState::NEEDS_PIN` event. If this
 method is sent when the authenticator is not in a state to receive a client

doc/historical/scenarios.md

@@ -59,7 +59,7 @@ sequenceDiagram
 1. user is shown a list of credentials, filtered by assertion options and ordered by most relevant based on the origin provided
     - invalid passkeys should not be shown? (because they won't work at all, and for phishing protection), but irrelevant passwords can be shown
     - This may cause issues for some origins if they're not registered properly.
-    - Technically, it's the responsibilty of the RP to validate the origin. If the origin is wrong, that's part of the authenticator data, and the RP can reject it. So even if a third-party phisher initiated the assertion from another site, the attacker couldn't use the credentials, because the RP wouldn't recognize the origin. So it might be OK to allow other passkeys to sign the assertion.
+    - Technically, it's the responsibility of the RP to validate the origin. If the origin is wrong, that's part of the authenticator data, and the RP can reject it. So even if a third-party phisher initiated the assertion from another site, the attacker couldn't use the credentials, because the RP wouldn't recognize the origin. So it might be OK to allow other passkeys to sign the assertion.
 1.  user scrolls and selects the relevant credential
 1. backend sends ID back to frontend, which pulls the corresponding credential and sends back to client
 1. browser receives credentials,