more typo fixes

2 files changed, 5 insertions, 5 deletions

diff --git a/app/views/pages/technology/client/en.haml b/app/views/pages/technology/client/en.haml
index 40721f4..c4f82b5 100644
--- a/app/views/pages/technology/client/en.haml
+++ b/app/views/pages/technology/client/en.haml
@@ -64,11 +64,11 @@
 
 %p
   %b The branded client
-  will but customized with the name and graphics of the service provider using the LEAP Platform. It will be pre-configured to work the with service provider.
+  will be customized with the name and graphics of the service provider using the LEAP Platform. It will be pre-configured to work the with service provider.
 
 %p
   %b The unbranded client
-  will work with any service provider that runs the LEAP platform. When the user first runs the unbranded client, they will be presented with a list of available service provider and the option to type in the name of a provider that is not in the list. Once the user picks a provider, the client will download a file from the provider that defines the capabilities of the provider and allows the client to autoconfigure itself for use with that provider.
+  will work with any service provider that runs the LEAP platform. When the user first runs the unbranded client, they will be presented with a list of available service providers and the option to type in the name of a provider that is not in the list. Once the user picks a provider, the client will download a file from the provider that defines the capabilities of the provider and allows the client to autoconfigure itself for use with that provider.
 
 
 %h1 Trust issues
diff --git a/app/views/pages/technology/identity/en.haml b/app/views/pages/technology/identity/en.haml
index f90d07b..27c8b8b 100644
--- a/app/views/pages/technology/identity/en.haml
+++ b/app/views/pages/technology/identity/en.haml
@@ -10,13 +10,13 @@
 
 %p NickID is based on a federated structure where the difficult work is pushed to the service providers. Each provider is responsible for the due diligence of properly signing the keys of other providers, akin to the distributed web of trust model of OpenPGP. Providers also are responsible for signing the keys of their users, akin to the Certificate Authority model.
 
-%p When a user sends or receives a message, their software will discovery the other party's key and trace a chain of signature's back to the user's service provider. NickID allows for identity that is verified through an end-to-end trust path from any user to any other user in a way that can be automated and is human memorable (e.g. identity in the form user@example.com).
+%p When a user sends or receives a message, their software will discover the other party's key and trace a chain of signature's back to the user's service provider. NickID allows for identity that is verified through an end-to-end trust path from any user to any other user in a way that can be automated and is human memorable (e.g. identity in the form user@example.com).
 
 %h1 Users are not websites
 
 %p What about WebID or BrowserID (Mozilla Personas)? These are both interesting cryptographic identity standards that are gaining support and implementations. So why do we need something new?
 
-%p These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a FWoT could be combined with something like BrowserID/Personas.
+%p These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a Federated Web of Trust could be combined with something like BrowserID/Personas.
 
 %h1 Attacks and countermeasures
 
@@ -42,4 +42,4 @@
 
 %p In order to prevent attack 3, the user's client software will be able to use the response of a notary as the initial key discovery, and to proxy a request to one notary through another. Each notary request will be encrypted to the public key of that notary.
 
-%p For this to work, client software that supports NickID will come pre-seeded with a list of notaries and their public keys. Although this sounds like a repeat of the problems associated with the Certificate Authority system, the notaries are actually quite different. Rather than placing irrevocable trust in an authority, clients are only using the notaries for a very narrowly defined ability to provide network perspective.
\ No newline at end of file
+%p For this to work, client software that supports NickID will come pre-seeded with a list of notaries and their public keys. Although this sounds like a repeat of the problems associated with the Certificate Authority system, the notaries are actually quite different. Rather than placing irrevocable trust in an authority, clients are only using the notaries for a very narrowly defined ability to provide network perspective.