Merge pull request #157 from dappsec/master

Fixing some typos in Getting Started Guide docs - thanks for the PR!

docs/GettingStartedAriesDev/AriesBigPicture.md

@@ -13,16 +13,16 @@ The agents in the picture shares many attributes:
   - That is often backend enterprise systems for enterprise agents
   - Business rules for cloud agents are often about the routing of messages to and from edge agents
 
-While there can be many other agent setups, the picture above shows the most common ones - edge agents for people, edge agents for organizations and cloud agents for routing messages (although cloud agents could be edge agents. Sigh...). A signifcant emerging use case missing from that picture are agents embedded within/associated with IoT devices. In the common IoT case, IoT device agents are just varients of other edge agents, connected to the rest of the ecosystem through a cloud agent. All the same principles apply.
+While there can be many other agent setups, the picture above shows the most common ones - edge agents for people, edge agents for organizations and cloud agents for routing messages (although cloud agents could be edge agents. Sigh...). A significant emerging use case missing from that picture are agents embedded within/associated with IoT devices. In the common IoT case, IoT device agents are just variants of other edge agents, connected to the rest of the ecosystem through a cloud agent. All the same principles apply.
 
-Misleading in the picture is that (almost) all agents connect directly to the Ledger network. In this picture it's the Sovrin ledger, but that could be any Indy network (e.g. set of nodes running indy-node software) and in future, ledgers from other providers. That implies most agents embed the ledger SDK (e.g. indy-sdk) and makes calls to the ledger SDK to interact with the ledger and other SDK controlled resources (e.g. secure storage). Thus, unlike what is implied in the picture, edge agents (commonly) do not call an cloud agent to interact with the ledger - they do it directly. Super small IoT devices are an instance of an exception to that - lacking compute/storage resources and/or connectivity, they might communicate with a cloud agent that would communicate with the ledger.
+Misleading in the picture is that (almost) all agents connect directly to the Ledger network. In this picture it's the Sovrin ledger, but that could be any Indy network (e.g. set of nodes running indy-node software) and in future, ledgers from other providers. That implies most agents embed the ledger SDK (e.g. indy-sdk) and makes calls to the ledger SDK to interact with the ledger and other SDK controlled resources (e.g. secure storage). Thus, unlike what is implied in the picture, edge agents (commonly) do not call a cloud agent to interact with the ledger - they do it directly. Super small IoT devices are an instance of an exception to that - lacking compute/storage resources and/or connectivity, they might communicate with a cloud agent that would communicate with the ledger.
 
 While current Aries agents currently only support Indy-based ledgers, the intention is to add support for other ledgers.
 
 The (most common) purpose of cloud agents is to enable secure and privacy preserving routing of messages between edge agents. Rather than messages going directly from edge agent to edge agent (which is often impossible - for example sending to a mobile agent), messages sent from edge agent to edge agent are routed through a sequence of cloud agents. Some of those cloud agents might be controlled by the sender, some by the receiver and others might be gateways owned by agent vendors (called "Agencies"). In all cases, an edge agent tells routing agents "here's how to send messages to me", so a routing agent sending a message only has to know how to send a peer-to-peer message. While quite complicated, the protocols used by the agents largely take care of this complexity, and most developers don't have to know much about it.
 
 Note the many caveats in this section - "most common", "commonly", etc. There are many small building blocks available in Aries and underlying components that can be combined in infinite ways. We recommend not worrying about the alternate use cases for now. Focus on understanding the common use cases while remembering that other configurations are possible.
 
-We also recommend **not** digging into all the layers described here. Just as you don't have to know how TCP/IP works to write an web app, you don't need to know how indy-node or indy-sdk work to be able to build your first Aries-based application. Later in this guide we'll covering the starting point you do need to know.
+We also recommend **not** digging into all the layers described here. Just as you don't have to know how TCP/IP works to write a web app, you don't need to know how indy-node or indy-sdk work to be able to build your first Aries-based application. Later in this guide we'll covering the starting point you do need to know.
 
 > Back to the [Aries Developer - Getting Started Guide](README.md).

docs/GettingStartedAriesDev/AriesDeveloperDemos.md

@@ -10,12 +10,12 @@ This demo uses agents (and an Indy ledger), but doesn't implement a controller a
 
 ## Python Controller demo
 
-Run this demo to see a couple of simple Python controllers implementations for Alice and Faber. Like the previous demo, this shows the agents connecting, Faber issuing a credential to Alice and then requesting a proof based on the credential. Running the demo is simple, but there's a lot for a developer to learn from the code.
+Run this demo to see a couple of simple Python controller implementations for Alice and Faber. Like the previous demo, this shows the agents connecting, Faber issuing a credential to Alice and then requesting a proof based on the credential. Running the demo is simple, but there's a lot for a developer to learn from the code.
 
 [Python-based Alice/Faber Demo](../../demo/README.md)
 
 ## Web App Sample - Email Verification Service
 
-This live service implements a real credential issuer - verifying a users email address when connecting to an agent and then issuing a "verified email address" credential. This service is used the [IIWBook Demo](https://vonx.io/how_to/iiwbook).
+This live service implements a real credential issuer - verifying a user's email address when connecting to an agent and then issuing a "verified email address" credential. This service is used the [IIWBook Demo](https://vonx.io/how_to/iiwbook).
 
 [Email Verification Service](https://github.com/bcgov/indy-email-verification)

docs/GettingStartedAriesDev/AriesMessaging.md

@@ -8,10 +8,10 @@ Given the underlying secure messaging layer (routing and encryption covered late
 * The "issue credential" protocol enables an agent to issue a credential to another agent.
 * The "present proof" protocol enables an agent to request and receive a proof from another agent.
 
-Each protocol has a specification that defines the protocol's messages, one or more roles for the different participants, and a state machine that defines the state transitions triggered by the messages. For example, in the connection protocol, the message are "invitation", "connectionRequest" and "connectionResponse", the roles are "inviter" and "invitee", and the states are "invited", "requested" and "connected". Each participant in an instance of a protocol tracks the state based on the messages they've seen.
+Each protocol has a specification that defines the protocol's messages, one or more roles for the different participants, and a state machine that defines the state transitions triggered by the messages. For example, in the connection protocol, the messages are "invitation", "connectionRequest" and "connectionResponse", the roles are "inviter" and "invitee", and the states are "invited", "requested" and "connected". Each participant in an instance of a protocol tracks the state based on the messages they've seen.
 
 Code for protocols are implemented as externalized modules from the core agent code so that they can be included (or not) in an agent deployment. The protocol code must include the definition of a state object for the protocol, handlers for the protocol messages, and the events and administrative messages that are available to the controller to inject business logic into the running of the protocol. Each administrative message becomes part of the REST API exposed by the agent instance.
 
 Developers building Aries agents for a particular use case will generally focus on building controllers. They must understand the protocols that they are going to need, including the events the controller will receive, and the protocol's administrative messages exposed via the REST API. From time to time, such Aries agent developers might need to implement their own protocols.
 
-> Back to the [Aries Developer - Getting Started Guide](README.md).
+> Back to the [Aries Developer - Getting Started Guide](README.md).

docs/GettingStartedAriesDev/AriesRoutingExample.md

@@ -38,7 +38,7 @@ Let's look at the `did-communication` service data in the DIDDocs generated by B
 - Bob and Alice:
   - The `serviceEndpoint` that Bob tells Alice about is the endpoint for the Agency.
 
-    - We'll use for the endpoint the Agency's public DID. That way the Agency can change rotate the keys for the endpoint without all of it's clients from having to update every DIDDoc with the new key.
+    - We'll use for the endpoint the Agency's public DID. That way the Agency can change rotate the keys for the endpoint without all of its clients from having to update every DIDDoc with the new key.
 
   - The `recipientKeys` entry is a key reference for Bob's iPhone specifically for Alice.
   - The `routingKeys` entries is a reference to the public key for the Routing Agent.
@@ -69,7 +69,7 @@ We'll start the process with Alice sending an out of band connection invitation
 - Bob's iPhone agent generates a new DID for Alice and prepares, and partially completes, a DIDDoc
 - Bob messages the Routing Agent to send the newly created DID and to get a new public key for the Alice relationship.
   - The Routing Agent records the DID for Alice and the keypair to be used for messages from Alice.
-- The Routing Agent sends the the DID to the Agency to let the Agency know that messages for the new DID are to go to the Routing Agent.
+- The Routing Agent sends the DID to the Agency to let the Agency know that messages for the new DID are to go to the Routing Agent.
 - The Routing Agent sends the data to Bob's iPhone agent.
 - Bob's iPhone agent fills in the rest of the DIDDoc:
   - the public key for the Routing Agent for the Alice relationship

docs/GettingStartedAriesDev/DecentralizedIdentityDemos.md

@@ -6,19 +6,19 @@ The following are some demos that you can go through to see verifiable credentia
 
 The Hyperledger Indy community is littered with "Alice and Faber" demos. Alice is a former student of [Faber College](https://en.wikipedia.org/wiki/Animal_House) (motto: Knowledge is Good), and is offered from Faber a verifiable credential that she can use to prove her educational accomplishments. Alice proves the claims in the credential to get a job at ACME Corp, and then uses a credential about her job at ACME Corp. to get a loan from Thrift Bank.
 
-The edX course version of the Alie/Faber story is good if you are new to Indy because in going through the story you get a web interface to see the interactions/technical steps in establishing connections between agents and the process for issuing and verifying credentials. **DO NOT** look into the underlying code because it is not maintained, and it is out-of-date.
+The edX course version of the Alice/Faber story is good if you are new to Indy because in going through the story you get a web interface to see the interactions/technical steps in establishing connections between agents and the process for issuing and verifying credentials. **DO NOT** look into the underlying code because it is not maintained, and it is out-of-date.
 
 We recommend using the "In Browser" steps to run the demo vs. getting things running on your local machine.
 
 Link: [Alice and Faber - edX Version](https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md)
 
 ### BC Gov's OrgBook and Greenlight
 
-BC Gov's Verifiable Organizations Network (VON) project implemented the first production Indy app (TheOrgBook, and now just "OrgBook") that exists to bootstrap verifiable credentials ecosystems. The Greenlight use case is a demo showing how verifiable credentials can be used for reducing the red tape businesses face in trying to get a government permit (for example, to open a restaurant). The business challenge addressed by Greenlight is figuring out what other permits and licenses need to be in place before a business can get the permit it actually wants. The demo simulates a business identifying their goal permit, seeing a roadmap of the prerequisite credentials already collected and still needed, and using links to get the needed credentials. Since in these early days fo decentralized identity, business don't have their own digital wallet, in applying for each credential, each permitting service is using OrgBook to get proof of the prerequisite credentials, and issuing the new credential back to the OrgBook.
+BC Gov's Verifiable Organizations Network (VON) project implemented the first production Indy app (TheOrgBook, and now just "OrgBook") that exists to bootstrap verifiable credentials ecosystems. The Greenlight use case is a demo showing how verifiable credentials can be used for reducing the red tape businesses face in trying to get a government permit (for example, to open a restaurant). The business challenge addressed by Greenlight is figuring out what other permits and licenses need to be in place before a business can get the permit it actually wants. The demo simulates a business identifying their goal permit, seeing a roadmap of the prerequisite credentials already collected and still needed, and using links to get the needed credentials. Since in these early days of decentralized identity, business don't have their own digital wallet, in applying for each credential, each permitting service is using OrgBook to get proof of the prerequisite credentials, and issuing the new credential back to the OrgBook.
 
 If you are interested in using/contributing to VON and OrgBook, contact the folks from BC Gov using links on https://vonx.io.
 
-Link: [Greenlight](https://greenlight.orgbook.gov.bc.ca/) - choose the "City of Surrey - Busienss Licence"
+Link: [Greenlight](https://greenlight.orgbook.gov.bc.ca/) - choose the "City of Surrey - Business License"
 Link: [Information about Verifiable Organizations Network (VON)](https://vonx.io)
 Link: [OrgBook BC - Production Instance](https://orgbook.gov.bc.ca/)
 
@@ -28,4 +28,4 @@ The IIWBook demo was presented during the [Internet Identity Workshop](https://i
 
 Link: [IIWBook Demo](https://vonx.io/how_to/iiwbook)
 
-> Back to the [Aries Developer - Getting Started Guide](README.md).
+> Back to the [Aries Developer - Getting Started Guide](README.md).

docs/GettingStartedAriesDev/IndyBasics.md

@@ -1,6 +1,6 @@
 # Indy, Verifiable Credentials and Decentralized Identity Basics
 
-> **NOTE:** If you are developer building apps on top of Aries and Indy, you **DO NOT** need to know the nuts and bolts of Indy to build applications. You need to know about verifiable credentials and the concepts of self-soveriegn identity. But as an app developer, you don't need to do the Indy getting started pieces. Aries takes care of those details for you. The introduction linked here should be sufficient.
+> **NOTE:** If you are developer building apps on top of Aries and Indy, you **DO NOT** need to know the nuts and bolts of Indy to build applications. You need to know about verifiable credentials and the concepts of self-sovereign identity. But as an app developer, you don't need to do the Indy getting started pieces. Aries takes care of those details for you. The introduction linked here should be sufficient.
 
 If you are new to Indy and verifiable credentials and want to learn the core concepts, this [link](https://github.com/hyperledger/education/blob/master/LFS171x/docs/introduction-to-hyperledger-indy.md) provides a solid foundation into the goals and purpose of Indy including verifiable credentials, DIDs, decentralized/self-sovereign identity, the Sovrin Foundation and more. The document is the content of the Indy chapter of the Hyperledger edX [Blockchain for Business](https://www.edx.org/course/blockchain-for-business-an-introduction-to-hyperledger-technologies) course (which you could also go through). 
 
@@ -12,4 +12,4 @@ As well, **don't** use the guidance in the course to dive into the content about
 
 Indy provides an implementation of the basic functions required to implement a network for self-sovereign identity (SSI) - a ledger, client SDKs for interacting with the ledger, DIDs, and capabilities for issuing, holding and proving verifiable credentials.
 
-> Back to the [Aries Developer - Getting Started Guide](README.md).
+> Back to the [Aries Developer - Getting Started Guide](README.md).

docs/GettingStartedAriesDev/README.md

@@ -1,6 +1,6 @@
 # Becoming an Indy/Aries Developer
 
-This guide is to get you from (pretty much) zero to developing code for issuing (and verifying) credentials with your own Aries agent. On the way, you'll look at Hyperledger Indy and how it works, find out about the architecture and components of an Aries agent and it's underlying messaging protocols. Scan the list of topics below and jump in as soon as you hit a topic you don't know.
+This guide is to get you from (pretty much) zero to developing code for issuing (and verifying) credentials with your own Aries agent. On the way, you'll look at Hyperledger Indy and how it works, find out about the architecture and components of an Aries agent and its underlying messaging protocols. Scan the list of topics below and jump in as soon as you hit a topic you don't know.
 
 Note that in the guidance we have here, we include not only the links to look at, but we recommend that you **not** look at certain material to which you might naturally gravitate. That's because the material is out of date and will take you down some unnecessary rabbit holes. Keep your eyes on the goal - developing with Indy and Aries.
 
@@ -21,4 +21,4 @@ Note that in the guidance we have here, we include not only the links to look at
 * [Deeper Dive: Routing Example](AriesRoutingExample.md)
 * To Do: [Deeper Dive: Running and Connecting to an Indy Network](ConnectIndyNetwork.md)
 
-Want to help with this guide? Please add issues or submit a pull request to improve the document. Point out things that are missing, things to improve and especially things that are wrong.
+Want to help with this guide? Please add issues or submit a pull request to improve the document. Point out things that are missing, things to improve and especially things that are wrong.