anchor.diff:      </tr>
       <tr>
         <td><code>oauth.login</code></td>
  -      <td>This scope is used to indicate a login application, such as external login servers, can perform trusted operations, such as creating users not authenticated in the UAA.</td>
  +      <td>This scope is used to indicate a login app, such as external login servers, can perform trusted operations, such as creating users not authenticated in the UAA.</td>
       </tr>
       <tr>
         <td><code>approvals.me</code></td>
  
positive.code:       resource-ids: clients
  ```
  You can use the admin client to create additional clients.
  You will need a client with read/write access to the `scim` resource to create user accounts.
  The integration tests take care of this automatically by inserting client and user accounts as necessary to make the tests work.
  
  ### <a id='samples'></a>Sample Applications ###
  
  Two sample applications are included with the UAA: `/api` and `/app`.
  
  Run them with `./gradlew run` from the `uaa` root directory. All three apps, `/uaa`, `/api`, and `/app` get deployed simultaneously.
  
  #### <a id='api-application'></a>The API Sample Application ####
  
  An example resource server.
  It hosts a service that returns a list of mock applications under `/apps`.
  
  #### <a id='app-application'></a>The App Sample Application ####
  
  This is a user interface app (primarily aimed at browsers) that uses OpenId Connect for authentication (i.e. SSO) and OAuth2 for access grants.
  It authenticates with the Auth service, then accesses resources in the API service.
  Run it with `./gradlew run` from the `uaa` root directory.
  
  The application can operate in multiple different profiles according to the location (and presence) of the UAA server and the Login application.
  By default, the application looks for a UAA on `localhost:8080/uaa`, but you can change this by setting an environment variable (or System property) called `UAA_PROFILE`.
  In the application source code (`samples/app/src/main/resources`), you will find multiple properties files pre-configured with different likely locations for those servers.
  They are all in the form `application-UAA_PROFILE.properties`.
  The naming convention adopted is that the `UAA_PROFILE` is `local` for the localhost deployment, `vcap` for a `vcap.me` deployment, and `staging` for a staging deployment.
  The profile names are double-barreled (e.g. `local-vcap` when the login server is in a different location than the UAA server).
  
  ##### Use Cases #####
  
  1. See all apps
  
          GET /app/apps
  
      Browser is redirected through a series of authentication and access grant steps (which could be slimmed down to implicit steps not requiring user at some point), and then the photos are shown.
  
  2. See the currently logged in user details, a bag of attributes grabbed from the open id provider
  
          GET /app
  
  #### <a id='login-application'></a>Login Application ####
  
  A user interface for authentication.
  The UAA can also authenticate user accounts, but only if it manages them itself,
  and it only provides a basic UI.
  You can brand and customize the login app for non-native authentication and for more complicated UI flows, like user registration and password reset.
  
  The login application is itself an OAuth2 endpoint provider, but delegates those features to the UAA server.
  Therefore, configuration for the login application consists of locating the UAA through its OAuth2 endpoint URLs and registering the login application itself as a client of the UAA.
  There is a `login.yml` for the UAA locations, such as for a local `vcap` instance:
  
  ```yaml
  uaa:
  
negative.code: 
  This topic provides an overview of the User Account and Authentication (UAA) Server, the identity management service for Cloud Foundry
  
  The primary role of the UAA is as an OAuth2 provider, issuing tokens for client apps to use when they act on behalf of Cloud Foundry users.
  In collaboration with the login server, the UAA can authenticate users with their Cloud Foundry credentials, and can act as an SSO service using those, or other, credentials.
  
  The UAA has endpoints for managing user accounts and for registering OAuth2 clients, as well as various other management functions.
  
  ## <a id='quickstart'></a>Quick Start ##
  
  You can deploy the UAA locally or to Cloud Foundry.
  
  * [Deploy UAA Locally](#local)
  * [Deploy UAA to Cloud Foundry](#cf)
  
  ### <a id='local'></a>Deploy UAA Locally ###
  
  Follow the instructions below to deploy and run the UAA locally.
  
  1. In a terminal window, clone the UAA GitHub repository. 
  
      <pre class="terminal">
      $ git clone git://github.com/cloudfoundry/uaa.git
      </pre>
  
  2. Navigate to the directory where you cloned the UAA GitHub repository, then run the `./gradlew run` command to build and run all the components that
  comprise the UAA and the example programs, `uaa`, `samples/api`, and `samples/app`.
  
      <pre class="terminal">
      $ cd uaa
      $ ./gradlew run
      </pre>
  
  3. If successful, the three apps run together on a single instance of Tomcat
  listening on port 8080, with endpoints `/uaa`, `/app`, and `/api`.
  
  ### <a id='demo-local'></a>Use Local UAA ###
  
  Follow the steps below to access and use a locally-deployed UAA server.
  
  1. Run the UAA server as described in the [Deploy Locally](#local) section, above. 
  
  2. Open another terminal window. From the project base directory, run `curl -H "Accept: application/json" localhost:8080/uaa/login` to query the login endpoint about the system. For example:
  
      <pre class="terminal">
      $ curl -H "Accept: application/json" localhost:8080/uaa/login
  