anchor.diff:    ```
   
   When this client is not present in the cf-release manifest, Cloud Controller cannot manage UAA clients and an operator will receive a warning when creating or updating service brokers that advertise the `dashboard_client` properties discussed below.
  +<% end  %>
   
  -## <a id='broker-responsibilities'></a>Service Broker Responsibilities ##
  +## <a name='broker-responsibilities'></a>Service Broker Responsibilities ##
   
  -### <a id='registering-dashboard-client'></a>Registering the Dashboard Client ###
  +### <a name='registering-dashboard-client'></a>Registering the Dashboard Client ###
   
   1.  A service broker must include the `dashboard_client` field in the JSON response from its [catalog endpoint](api.html#catalog-mgmt) for each service implementing this feature. A valid response would appear as follows:
   
  
positive.code: 
  Since administrators may change the permissions of users at any time, the service should check this endpoint whenever a user uses the SSO flow to access the service's UI.
  
  ### <a id="on-scopes"></a> On Scopes
  
  Scopes let you specify exactly what type of access you need. Scopes limit access for OAuth tokens. They do not grant any additional permission beyond that which the user already has.
  
  
negative.code:       }
        ```
      The `dashboard_client` field is a hash containing three fields:
      - `id` is the unique identifier for the OAuth client that will be created for your service dashboard on the token server (UAA), and will be used by your dashboard to authenticate with the token server (UAA). If the client id is already taken, <%= vars.product_name  %> will return an error when registering or updating the broker.
      - `secret` is the shared secret your dashboard will use to authenticate with the token server (UAA).
      - `redirect_uri` is used by the token server as an additional security precaution. UAA will not provide a token if the callback URL declared by the service dashboard doesn't match the domain name in `redirect_uri`. The token server matches on the domain name, so any paths will also match; e.g. a service dashboard requesting a token and declaring a callback URL of `http://p-mysql.example.com/manage/auth` would be approved if `redirect_uri` for its client is `http://p-mysql.example.com/`.
  
  1. When a service broker which advertises the `dashboard_client` property for any of its services is [added or updated](managing-service-brokers.html), Cloud Controller will create or update UAA clients as necessary. This client will be used by the service dashboard to authenticate users.
  
  ### <a name='dashboard-url'></a>Dashboard URL ###
  
  A service broker should return a URL for the `dashboard_url` field in response to a [provision request](./api.html#provisioning). Cloud Controller clients should expose this URL to users. `dashboard_url` can be found in the response from Cloud Controller to create a service instance, enumerate service instances, space summary, and other endpoints.
  
  Users can then navigate to the service dashboard at the URL provided by `dashboard_url`, initiating the OAuth login flow.
  
  ## <a name='dashboard-responsibilities'></a>Service Dashboard Responsibilities ##
  
  ### <a name='oauth2-flow'></a>OAuth Flow ###
  
  When a user navigates to the URL from `dashboard_url`, the service dashboard should initiate the OAuth login flow. A summary of the flow can be found in [section 1.2 of the OAuth RFC](http://tools.ietf.org/html/rfc6749#section-1.2). OAuth expects the presence of an [Authorization Endpoint](http://tools.ietf.org/html/rfc6749#section-3.1) and a [Token Endpoint](http://tools.ietf.org/html/rfc6749#section-3.2). In <%= vars.product_name %>, these endpoints are provided by the UAA. Clients can discover the location of UAA from Cloud Controller's info endpoint; in the response the location can be found in the `token_endpoint` field.
  
  ```
  $ curl api.example.com/info
  