Removing my email from image + fixing typos

Author: alekspejovic

docs/src/admins.rst

@@ -17,13 +17,13 @@ To administer Ego, the admin must:
 
    a. Admin creates a new application in Ego with the client_id and password.
    b. Admin creates new policies with new policy names
-   c. Admin Assign permissions to users/groups to permit/deny them access to the new application and policies
+   c. Admin assigns permissions to users/groups to permit/deny them access to the new application and policies
 
-**4. Admin creates or deletes groups, assigns user/group permissions, expire tokens, etc. as necessary.**
+**4. Admin creates or deletes groups, assigns user/group permissions, revoke tokens, etc. as necessary.**
 
    For example, an administrator might want to:
 
-      - Create a new group called “QA”, whose members are all the people in the “QA department”
+      - Create a new group called **“QA”**, whose members are all the people in the “QA department”
       - Create a group called “Access Denied” with access level “DENY” set for every policy in Ego
       - Grant another user administrative rights (role ADMIN)
       - Add a former employee to the group “AccessDenied”, and revoke all of their active tokens.

docs/src/gettingstarted.rst

@@ -21,22 +21,23 @@ Using  `Docker <https://www.docker.com/>`_:
 
 Ego should now be deployed locally with the Swagger UI at http://localhost:8080/swagger-ui.html
 
-Alternatively, see the development :ref:`installation instruction `. instructions.
+Alternatively, see the `Installation instructions <installation.html>`_.
+
 
 How Ego Works
 -------------------------------------------
-**1.       An Ego administrator configures Ego.**
+**1.  An Ego administrator configures Ego.**
     - Registers a unique client-id and application password for each application that will use Ego for Authorization.
     - Creates a policy for every authorization scope that an application will use.
     - Registers users and groups, and sets them up with appropriate permissions for policies and applications.
 
 
-**2.     Ego grants secret authorization tokens to individual users to represent their permissions**
+**2.  Ego grants secret authorization tokens to individual users to represent their permissions.**
     - Authorization tokens expire, and can be revoked if compromised.
     - Individuals can issue tokens for part or all of their authority, and can limit the authority to specific applications.
     - Users (and programs operating on their behalf) can then use these tokens to access services.
 
-**3.     Individual services make a REST call to EGO to determine the user and authority represented by a token.**
+**3.  Individual services make a REST call to EGO to determine the user and authority represented by a token.**
     - Makes a call to Ego's check_token endpoint and validates the user's authorization to access the requested services.
 
 

docs/src/jwt.png

@@ -3,21 +3,23 @@ Tokens
 
 User Authentication Tokens
 ----------------------------------------------------
-Authentication concerns who the user is. User Authentication tokens are used to verify a user’s identity.
+Authentication concerns *who the user is*.
 
-Ego’s User Authentication tokens are signed JSON Web Tokens (see http://jwt.io) that Ego issues when a user successfully logs into Ego using their Google or Facebook credentials.
+User Authentication tokens are used to verify a user’s identity.
 
-Ego will then issue an authentication token, which confirms the user’s identity, and contains information about the user’s name, their role (user or administrator), and any applications, permissions, and groups associated with their Ego account.
+Ego’s User Authentication tokens are signed JSON Web Tokens (see http://jwt.io) that Ego issues when a user successfully logs into Ego using their Google or Facebook credentials.
 
-An authentication token contains all of the information that ego has about a given user, including which groups they are a part of, which applications they are authorized to use , which permissions they have to use those applications.
+Ego's authentication tokens confirm the user’s identity, and contain information about a user’s name, their role (user/administrator), and any applications, permissions, and groups associated with their Ego account etc.
 
-This data current as of the time the token is issued, and the token is digitally signed by Ego with a publicly available signing key that applications have to use to verify that an authentication token is valid. Most of Ego’s REST endpoints require an Ego authentication token to validate the user’s identity before operating on their data.
+This data is current as of the time the token is issued, and the token is digitally signed by Ego with a publicly available signing key that applications have to use to verify that an authentication token is valid. Most of Ego’s REST endpoints require an Ego authentication token to be provided in the authorization header, in order to validate the user’s identity before operating on their data.
 
 .. image :: jwt.png
 
 User Authorization Tokens
 ----------------------------------------------------
-Authorization concerns what a user is allowed to do.
+Authorization concerns *what a user is allowed to do*.
+
+User Authorization tokens are used to verify a user's permissions to execute on a desired scope.
 
 Ego’s User Authorization tokens are random numbers that Ego issues to users so they can interact with Ego-aware applications with a chosen level of authority.
 
@@ -27,12 +29,12 @@ Unlike passwords, Authorization tokens automatically expire, and they can be rev
 
 The user can then use their token with Ego-authorized applications as proof of who they are and what they are allowed to do. Typically, the user will configure a client program (such as SING, the client program used with SONG, the ICGC Metadata management service) with their secret token, and the program will then operate with the associated level of authority.
 
-In more detail, when an Ego-aware application wants to know if it authorized to do something on behalf of a given user, it just sends their user authorization token to Ego, and gets back the associated information about who the user is (their user id), and what they are allowed to do (the permissions associated with their token). If the permissions that the user have include the permission the application wants, the application know it is authorized to perform the requested service on behalf of the user.
+In more detail, when an Ego-aware application wants to know if it is authorized to do something on behalf of a given user, it just sends their user authorization token to Ego, and gets back the associated information about who the user is (their user id), and what they are allowed to do (the permissions associated with their token). If the permissions that the user have include the permission the application wants, the application know it is authorized to perform the requested service on behalf of the user.
 
 
 Application Authentication Tokens
 ----------------------------------------------------
 
 For security reasons, applications need to be able to prove to Ego that they are the legitimate applications that Ego has been configured to work with.
 
-For this reason, every Ego-aware application must be configured in Ego with it’s own unique client_id and password, and the application must send an authentication token with this information to Ego whenever it makes a request to get the identity and credentials associated with a user’s authorization token.
+For this reason, every Ego-aware application must be configured in Ego with it’s own unique CLIENT ID and CLIENT SECRET, and the application must send a token with this information to Ego whenever it makes a request to get the identity and credentials associated with a user’s authorization token.