Update index.md typos

docs/index.md

@@ -6,13 +6,13 @@ When you visit https://mail.google.com or https://outlook.live.com you want to s
 
 Once you have authenticated which User account you want to access, the software needs to determine how much functionality and data to give you access to. Low hanging fruit - you would be authorized to view the emails you have sent or received.
 
-Authorization also has a different meaning. If you read your emails through a mobile or desktop application then initially this software does not have permission to access your email. You will need to authenticate as you, and to authorize the email program to access your emails and to send new emails on your behalf. The email program does not really need your password, it only needs authorization. The benefit of granting authorization to an email program is that you could revoke the permission. Another benefit is that the email program cannot accidentally nor maliciously share access to your emails. You've only given authorization to this email application. A different application or email client would need to ask you for authorization. The email program cannot be hacked and leak your password since it never received the password. If the email client software is subsequently deemed to be a bag actor, then https://mail.google.com or https://outlook.live.com could revoke all permissions for it to access any user's accounts simultaneously.
+Authorization also has a different meaning. If you read your emails through a mobile or desktop application then initially this software does not have permission to access your email. You will need to authenticate as you, and to authorize the email program to access your emails and to send new emails on your behalf. The email program does not really need your password, it only needs authorization. The benefit of granting authorization to an email program is that you could revoke the permission. Another benefit is that the email program cannot accidentally nor maliciously share access to your emails. You've only given authorization to this email application. A different application or email client would need to ask you for authorization. The email program cannot be hacked and leak your password since it never received the password. If the email client software is subsequently deemed to be a bad actor, then https://mail.google.com or https://outlook.live.com could revoke all permissions for it to access any user's accounts simultaneously.
 
 This decoupling of user authentication and authorization - of users (you and me) of web applications (say of https://mail.google.com or https://outlook.live.com) of a granting authorization to third-party software (say email clients written by Google, Microsoft, or any other software vendor or websites) to a subset of functionality and data (perhaps an email client is only able to read your Google emails, but not your Google calendar entries or Google documents) - is most commonly implemented using OAuth2. We will come back to the wheres and hows and whys of OAuth2 later when its more interesting to do so.
 
 The UAA (named for User Authentication & Authorization) is a free, open source software program backed by a simple SQL database of your choice that you can use as the backbone of implementing and administrating user authentication and authorization across one or more applications that might share similar users and organizations. It was first released in 2011 and has been the stoic backbone of user authentication and authorization in Cloud Foundry, BOSH, and CredHub. It is visible within shared public Cloud Foundry distributions (for example, https://login.run.pivotal.io, https://login.fr.cloud.gov/login, and https://www.predix.io/login) and also operates within private Cloud Foundry deployments at hundreds of large companies around the world.
 
-It can be used within your company too. With the UAA you can delegate the creation of users, their roles within your organization/customer base, and their permissions within your applications. The UAA can be a bridge to other sources of truth about your users and their roles and permissions, such as Microsoft Active Director.
+It can be used within your company too. With the UAA you can delegate the creation of users, their roles within your organization/customer base, and their permissions within your applications. The UAA can be a bridge to other sources of truth about your users and their roles and permissions, such as Microsoft Active Directory.
 
 With the UAA you can allow users to authenticate with simple passwords, with tokens, and with multi-factor authentication. Users can authorize programs to access their data in other programs.
 
@@ -28,19 +28,19 @@ As an example, I want to use your application and you allow me to authenticate t
 
 On your site I click your "Login via GitHub" button.
 
-I would be redirected to https://github.com/ to first login if I were not already signed in. As Dr Nic Williams, I would login to GitHub as [@drnic](https://github.com/drnic). Since only I know my GitHub password, GitHub trusts that the `@drnic` account is me. Except GitHub doesn't truly trust me, so it asks me for a second form of proof. I take out my phone, open the Authy application (or another like Google Authenitcator) and copy in a 6 digit number. Finally GitHub believes that `@drnic` is me using two factors of authentication (2FA) - my password and my code from my phone.
+I would be redirected to https://github.com/ to first login if I were not already signed in. As Dr Nic Williams, I would login to GitHub as [@drnic](https://github.com/drnic). Since only I know my GitHub password, GitHub trusts that the `@drnic` account is me. Except GitHub doesn't truly trust me, so it asks me for a second form of proof. I take out my phone, open the Authy application (or another like Google Authenticator) and copy in a 6 digit number. Finally GitHub believes that `@drnic` is me using two factors of authentication (2FA) - my password and my code from my phone.
 
 Next, GitHub asks me if I grant your application permission - authorization - to access my GitHub account. Your application only wants my personal profile information - my name and email - and so that is all I am asked to authorize. I click "Authorize".
 
 GitHub now redirects me back to your web application or mobile application. Your application is given my personal information - my email and name - and your application respects GitHub's decision and the information it receives from GitHub. If GitHub believes that I am `@drnic` and my name is "Dr Nic Williams", then your application believes it too. Your application never has to ask me for my name nor email.
 
-Your example application also supports organizations - as a user I can see and edit content only within teams/organizations that I belong.
+Your example application also supports organizations - as a user I can see and edit content only within teams/organizations that I belong to.
 
-Instead of you development team spending a lot of time implementing its own UI and business logic for orgnaizations - how to invite and revoke people from teams - you defer again to GitHub. When GitHub redirected me back to your application, it also told you which GitHub organizations I am a member of, and which teams of each organization. For example, I am a member of the [@starkandwayne](https://github.com/starkandwayne) - an excellent consultancy for Cloud Foundry, Kubernetes, and enterprise cloud systems. Your application also has a `@starkandwayne` organization so I am automatically granted permission (authorization) to read and modify its contents within your application.
+Instead of your development team spending a lot of time implementing its own UI and business logic for organizations - how to invite and revoke people from teams - you defer again to GitHub. When GitHub redirected me back to your application, it also told you which GitHub organizations I am a member of, and which teams of each organization. For example, I am a member of the [@starkandwayne](https://github.com/starkandwayne) - an excellent consultancy for Cloud Foundry, Kubernetes, and enterprise cloud systems. Your application also has a `@starkandwayne` organization so I am automatically granted permission (authorization) to read and modify its contents within your application.
 
 If not Github, your application might use Google Accounts (`[email protected]` belongs to a `@starkandwayne.com` Google Account) or an in-house Microsoft Active Directory organization.
 
-In all these variations your application does not have to touch or store or rotate passwords or two-factor authentication systems. It does not have to implement UIs for the management of membership of organizations/teams. And anything you didn't have to implement is something you don't have to continually maintain over the next decade. You've kept your application simpler, and thus its behavior more well known to more people.
+In all these variations your application does not have to touch or store or rotate passwords or two-factor authentication systems. It does not have to implement UIs for the management of membership of organizations/teams. And anything you didn't have to implement is something you don't have to continually maintain over the next decade. You've kept your application simpler, and thus its behavior is more well known to more people.
 
 ## Why did I write this book?
 
@@ -58,7 +58,7 @@ The UAA web interface was also never aesthetically pleasing; was not visited for
 
 The UAA web interface does not perform any administration or configuration functions. It only allows people to sign in, to setup and use multi-factor authentication (also known as MFA, two-factor authentication, or 2FA), to confirm that a third-party application is allowed to access their UAA personal information, or to revoke that permission at a later time.
 
-An administration user must interact with the UAA API or use a primitive CLI to add or modify users and third-party client applications. APIs and low-level CLIs are fantastic for power users, but they not very welcoming to myself: a brand-new user for seven years in a row.
+An administration user must interact with the UAA API or use a primitive CLI to add or modify users and third-party client applications. APIs and low-level CLIs are fantastic for power users, but they are not very welcoming to myself: a brand-new user for seven years in a row.
 
 The UAA could be the user authentication (who am I?) and authorization (what am I allowed to do?) backend for every web application or API, but I don't feel like the UAA team, its sponsors (primarily Pivotal), nor the Cloud Foundry Foundation do the UAA justice and promote it for such a broad mission. It has no dedicated marketing site to learn more, nor a simple Docker image to get started.
 
@@ -70,7 +70,7 @@ Along the way I wrote the `uaa-deployment` CLI to make it much easier to deploy
 
 I hope you discover the incredible power of the UAA and learn to feel empowered to delegate to it all your user authentication and authorization needs. Once you start using the UAA there will be so much that you no longer have to implement, or have to apologise for not having implemented yet.
 
-## Pronounciation, Spelling, and Grammar
+## Pronunciation, Spelling, and Grammar
 
 In my head I pronounce UAA "You Aye Aye", rather than "You Ah", or "User Authentication and Authorization". As such, in the text of this book you'll see me writing "a UAA", rather than "an UAA". It sounds better.
 
@@ -94,4 +94,4 @@ If you spot a missspelling, please you are welcome to click the Edit pencil at t
 
 If you spot bad grammar, wafflingly long sentences or a list of two or more items that do not end with an Oxford Comma then please click the Edit pencil at the top and offer to correct it. I really appreciate it.
 
-If you spot deliberate irony, like deliberate mistakes as examples then you can smile and move on.
+If you spot deliberate irony, like deliberate mistakes as examples then you can smile and move on.