docs: fix typos

website/docs/developer-section/quickstart/create-custom-renderer.md

@@ -8,7 +8,7 @@ OA documents are both readable by machines as well as by humans. Every OA docume
 
 In this guide, we will build and deploy the renderer to display data from a 📜 Certificate of Completion.
 
-This renderer is a static website that will be embedded in compliant OA viewer. It will take in the OA document in the raw form and generates the corresponding HTML code for rendering.
+This renderer is a static website that will be embedded in compliant OA viewer. It will take in the OA document in the raw form and generate the corresponding HTML code for rendering.
 
 ## Prerequisites
 
@@ -32,7 +32,7 @@ rm -rf .git
 
 ### Clean the template
 
-In order to fully understand how developing a renderer work, we will start by cleaning it a bit:
+In order to fully understand how developing a renderer works, we will start by cleaning it a bit:
 
 - remove the folder `src/templates/customTemplate`
 - remove the folder `src/integration`
@@ -123,7 +123,7 @@ The `name` key is a compulsory key to describe the type of OA document. In this
 
 #### `recipient`
 
-OA documents do not have a strict data structure and allows issuers of documents to define their own data schema. The `recipient` object is a user-defined object that describes who the certificate is conferred to. In this case, you may replace `John Doe` with your name.
+OA documents do not have a strict data structure and allow issuers of documents to define their own data schema. The `recipient` object is a user-defined object that describes who the certificate is conferred to. In this case, you may replace `John Doe` with your name.
 
 In the next section, you will learn more about the OA document schema and how you may define your own data structure. For this guide, we will stick to this simple document.
 
@@ -145,7 +145,7 @@ awarded to
 John Doe
 ```
 
-The first step consist of creating a file `src/templates/coc/template.tsx` with the following content:
+The first step consists of creating a file `src/templates/coc/template.tsx` with the following content:
 
 ```jsx harmony
 import React, { FunctionComponent } from "react";
@@ -225,11 +225,11 @@ export const templates = [
 ];
 ```
 
-- `templates` must be an array where each element correspond to a view (or a tab). Here we need only one view.
+- `templates` must be an array where each element corresponds to a view (or a tab). Here we need only one view.
 - Each view must define the following property:
-  - `id` which must be a uniq identifier for this template configuration.
+  - `id` which must be a unique identifier for this template configuration.
   - `label` which will be displayed by tab in the application loading the renderer.
-  - `template` which is is the component that will be displayed.
+  - `template` which is the component that will be displayed.
 
 ### Renderer template configuration
 

website/docs/developer-section/quickstart/create-verifiable-document-issuer.md

@@ -22,7 +22,7 @@ You should also have had MetaMask installed in your browser and created a wallet
 
 1. [Download MetaMask](https://metamask.io/download/).
    - After successfully downloading MetaMask, open the extension and the application will guide you with wallet creation.
-2. Transfer some test ethers from any of your prefered testing networks to your created wallet address.
+2. Transfer some test ethers from any of your preferred testing networks to your created wallet address.
 
 ### Verifiable Document Components
 
@@ -73,7 +73,7 @@ Now that we have a basic React application set up and the necessary dependencies
 
 ### Initialising MetaMask
 
-When you [installed MetaMask](/docs/developer-section/quickstart/create-verifiable-document-issuer#metamask) on your browser, it injected a [global API](https://docs.metamask.io/guide/ethereum-provider.html) into the web application at `window.etherem`. We use this API to get a [Signer](https://docs.ethers.io/v5/api/signer/) so that we can interact with smart contracts on the Ethereum blockchain.
+When you [installed MetaMask](/docs/developer-section/quickstart/create-verifiable-document-issuer#metamask) on your browser, it injected a [global API](https://docs.metamask.io/guide/ethereum-provider.html) into the web application at `window.ethereum`. We use this API to get a [Signer](https://docs.ethers.io/v5/api/signer/) so that we can interact with smart contracts on the Ethereum blockchain.
 
 We'll create separate files for our API calls. For example, in `services/account.tsx`:
 

website/docs/developer-section/quickstart/oa-embedded-html.md

@@ -76,7 +76,7 @@ For simplicity, we will be using the contents from the [sample HTML file](https:
 ### Replace the button link with your Verify URL
 
 1. Copy the [sample HTML file template](https://github.com/Open-Attestation/oa-embedded-html/blob/master/samples/healthcert-pdt-oa-embedded-uri-fragment-sample.html) and paste it into a text editor of your choice
-2. Replace the [the URL on this line](https://github.com/Open-Attestation/oa-embedded-html/blob/master/samples/healthcert-pdt-oa-embedded-uri-fragment-sample.html#L105) with your Verify URL from earlier
+2. Replace [the URL on this line](https://github.com/Open-Attestation/oa-embedded-html/blob/master/samples/healthcert-pdt-oa-embedded-uri-fragment-sample.html#L105) with your Verify URL from earlier
 
    ```html
    <p>

website/docs/docs-section/faq.md

@@ -104,11 +104,11 @@ Below are the pros and cons of each approach.
     </tbody>
 </table>
 
-#### How can I have an estimation of the costs involved in using the smart contracts ?
+#### How can I have an estimation of the costs involved in using the smart contracts?
 
 You can refer to the page [Contract Costs](/docs/docs-section/appendix/contract-costs) for a breakdown of the estimations.
 
-#### What is gas ?
+#### What is gas?
 
 For more information on Gas and Gas Prices, check out [this article](https://ethereum.stackexchange.com/questions/3/what-is-meant-by-the-term-gas)
 

website/docs/docs-section/how-does-it-work/comparison.md

@@ -9,7 +9,7 @@ In this section, we will discuss the differences between Ethereum Smart Contract
 
 By using Ethereum Smart Contracts, you will of course be bound to the Ethereum infrastructure. Every transaction will be stored in the Blockchain. Forever. For basic issuance, you won't need to maintain any infrastructure on your own. On top of that you will be able to monitor every transaction that happened, and detect abnormal activities. For instance if someone manages to steal your wallet private key, you will find evidence directly on the Blockchain.
 
-Regarding DID, you won't need to maintain any infrastructure as well... or maybe you will need. It will depend on your needs. Indeed, No records of your transactions will be made by default. DID will work straight, out of the box. However, if you want to keep track on every transaction, you will have to do it yourself. One could ask: "Why would I need to track every transaction ?". Unlike for Ethereum Smart Contracts, if a user manage to steal your signing private key, you will never be aware of it.
+Regarding DID, you won't need to maintain any infrastructure as well... or maybe you will need. It will depend on your needs. Indeed, No records of your transactions will be made by default. DID will work straight, out of the box. However, if you want to keep track of every transaction, you will have to do it yourself. One could ask: "Why would I need to track every transaction ?". Unlike for Ethereum Smart Contracts, if a user manages to steal your signing private key, you will never be aware of it.
 
 ## Environment
 
@@ -39,7 +39,7 @@ For DID, it's the opposite, everything is private.
 
 Revocation is part of our Ethereum Smart Contracts.
 
-As of today, its possible to revoke a document if a document store has been declared in its revocation block. You can revoke a document [using a document store](/docs/integrator-section/verifiable-document/did/revoking-document) or [with an OCSP](/docs/integrator-section/verifiable-document/did/revoking-document-ocsp).
+As of today, it's possible to revoke a document if a document store has been declared in its revocation block. You can revoke a document [using a document store](/docs/integrator-section/verifiable-document/did/revoking-document) or [with an OCSP](/docs/integrator-section/verifiable-document/did/revoking-document-ocsp).
 
 Note that if you do use revocation for `DID`, you still need to have at least 1 transaction with the ethereum blockchain to deploy a `documentStore`, which means `DID` flow is not free anymore.
 

website/docs/docs-section/how-does-it-work/document-integrity.md

@@ -5,7 +5,7 @@ sidebar_label: Document Integrity
 
 OpenAttestation ensures that the content of the document has not been modified since the document has been created, with exception of data removed using the built-in [obfuscation mechanism](/docs/developer-section/libraries/remote-files/open-attestation#obfuscating-data). Let's explore how it works.
 
-In the tutorial, we have learnt how to [wrap a document](/docs/integrator-section/verifiable-document/ethereum/wrapping-document) and [issue it](/docs/integrator-section/verifiable-document/ethereum/issuing-document) into a document store. However, we didn't explain what these actions were doing and why they are necessary.
+In the tutorial, we have learned how to [wrap a document](/docs/integrator-section/verifiable-document/ethereum/wrapping-document) and [issue it](/docs/integrator-section/verifiable-document/ethereum/issuing-document) into a document store. However, we didn't explain what these actions were doing and why they are necessary.
 
 ## Wrapping a document
 

website/docs/docs-section/how-does-it-work/issuance-identity.md

@@ -3,7 +3,7 @@ title: Issuance Identity
 sidebar_label: Issuance Identity
 ---
 
-OpenAttestation uses the Domain Name System (DNS) as the method of issuer identity verification. A one-liner introduction to the DNS system can be summarised as: "Phonebook for the Internet". It's primary purpose is to resolve human readable names such as "google.com", or "openattestation.com", etc. to a set of records. The most common records are 'A records', which resolve to IP addresses - this allows network routing to operate over the Internet.
+OpenAttestation uses the Domain Name System (DNS) as the method of issuer identity verification. A one-liner introduction to the DNS system can be summarised as: "Phonebook for the Internet". Its primary purpose is to resolve human readable names such as "google.com", or "openattestation.com", etc. to a set of records. The most common records are 'A records', which resolve to IP addresses - this allows network routing to operate over the Internet.
 
 For OpenAttestation, we are using the TXT type of record, which simply allows us to store textual data. The textual data we store indicates the Document Store that the domain administrator trusts.
 

website/docs/docs-section/how-does-it-work/issuance-status.md

@@ -3,7 +3,7 @@ title: Issuance Status
 sidebar_label: Issuance Status
 ---
 
-OpenAttestation checks that the document has been issued and that it's issuance status is in good standing (for instance, that it hasn't been revoked). As of today, OpenAttestation supports two ways to issue documents: DIDs and Ethereum Smart Contracts.
+OpenAttestation checks that the document has been issued and that its issuance status is in good standing (for instance, that it hasn't been revoked). As of today, OpenAttestation supports two ways to issue documents: DIDs and Ethereum Smart Contracts.
 
 ## Ethereum Smart Contracts
 
@@ -89,10 +89,10 @@ An [`ethr` DID document](https://dev.uniresolver.io/1.0/identifiers/did:ethr:0x6
 }
 ```
 
-Three important information can be found:
+Three important informations can be found:
 
 - the DID identifier (here `did:ethr:0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69`). It's used to identify the DID and must be added into the `issuer.id` property of the document.
-- The DID controller (here `did:ethr:0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69#controller`). It's used to identify which public key control the DID and must be added into the `issuer.identityProof.key` property of the document. It's also worth to note that the value is equal to the DID identifier, appended with `#controller`.
+- The DID controller (here `did:ethr:0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69#controller`). It's used to identify which public key controls the DID and must be added into the `issuer.identityProof.key` property of the document. It's also worth noting that the value is equal to the DID identifier, appended with `#controller`.
 - The ethereum address associated to the DID controller (here `0x6813eb9362372eef6200f3b1dbc3f819671cba69`). We will use it to verify the signature.
 
 > You can find an example of document using DID in our [guide](/docs/integrator-section/verifiable-document/did/raw-document).
@@ -116,7 +116,7 @@ A proof of signature looks like:
 - `signature` is the signed `merkleRoot`
 - `verificationMethod` is the DID controller.
 
-That's all the information that we need to verify that the document has been signed with the correct private key. Indeed,`ethr` DID uses [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) with [Secp256k1](https://en.bitcoin.it/wiki/Secp256k1) as parameter of the elliptic curve which provides an interesting property: when we verify a signature, using the initial value (`merkleRoot`), and the signed value (`signature`) it will recover the ethereum address associated with the private key used. We can then compare the ethereum address from the DID document, with the ethereum address returned by the verification. If it matches, the signature is valid.
+That's all the information that we need to verify that the document has been signed with the correct private key. Indeed, `ethr` DID uses [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) with [Secp256k1](https://en.bitcoin.it/wiki/Secp256k1) as parameter of the elliptic curve which provides an interesting property: when we verify a signature, using the initial value (`merkleRoot`), and the signed value (`signature`) it will recover the ethereum address associated with the private key used. We can then compare the ethereum address from the DID document, with the ethereum address returned by the verification. If it matches, the signature is valid.
 
 If you want to dig more on ECDSA, you can read this guide from [Yos Riady](https://yos.io/2018/11/16/ethereum-signatures/).