diff --git a/doc/source/configuration/block-storage/service-token.rst b/doc/source/configuration/block-storage/service-token.rst
index 108f4b0db20..1c48552f2ee 100644
--- a/doc/source/configuration/block-storage/service-token.rst
+++ b/doc/source/configuration/block-storage/service-token.rst
@@ -53,15 +53,20 @@ following:
 3.  Also in that section, fill in the appropriate configuration for
     your service user (``username``, ``project_name``, etc.)
 
-.. note::
-   There is no configuration required for a service to *receive*
-   service tokens.  This is automatically handled by the keystone
-   middleware used by each service (beginning with the Pike release).
+4.  If Cinder is going to receive service tokens from other services
+    it needs to have two options configured in the
+    ``[keystone_authtoken]`` section of the configuration file:
 
-   (The previous statement is true for the default configuration.  It
-   is possible for someone to change some settings so that service
-   tokens will be ignored.  See the :ref:`service-token-troubleshooting`
-   section below.)
+    ``service_token_roles``
+        The value is a list of roles; the service user passing the service
+        token must have at least one of these roles or the token will be
+        rejected. The default value is ``service``.
+
+    ``service_token_roles_required``
+        This is a boolean; the default value is ``False``.  It governs whether
+        the keystone middleware used by the receiving service will pay any
+        attention to the ``service_token_roles`` setting.  It should be set
+        to ``True``.
 
 .. _service-token-troubleshooting:
 
@@ -85,34 +90,14 @@ Identity Service (Keystone).
        requires Keystone validation (for example, the Swift backend) and the
        user token has expired.
 
-2.  Each receiving service, by default, is set up to accept service tokens.
-    There are two options to be aware of, however, that can affect whether or
-    not a receiving service (for example, Glance) will actually accept service
-    tokens.  These appear in the ``[keystone_authtoken]`` section of the
-    **receiving service** configuration file (for example,
-    ``/etc/glance/glance-api.conf``).
+2.  There are several things to pay attention to in Keystone:
 
-    ``service_token_roles``
-        The value is a list of roles; the service user passing the service
-        token must have at least one of these roles or the token will be
-        rejected.  (But see the next option.)  The default value is
-        ``service``.
-
-    ``service_token_roles_required``
-        This is a boolean; the default value is ``false``.  It governs whether
-        the keystone middleware used by the receiving service will pay any
-        attention to the ``service_token_roles`` setting.  (Eventually the
-        default is supposed to become True, but it's still False as of Stein.)
-
-3.  There are several things to pay attention to in Keystone:
-
-    * If you've decided to turn on ``service_token_roles_required`` for any of
-      the receiving services, then you must make sure that any service user who
-      will be contacting that receiving service (and for whom you want to
-      enable "service token" usage) has one of the roles specified in the
-      receiving services's ``service_token_roles`` setting.  (This is a matter
-      of creating and assigning roles using the Identity Service API, it's
-      not a configuration file issue.)
+    * When ``service_token_roles_required`` is enabled you must make sure that
+      any service user who will be contacting that receiving service (and for
+      whom you want to enable "service token" usage) has one of the roles
+      specified in the receiving services's ``service_token_roles`` setting.
+      (This is a matter of creating and assigning roles using the Identity
+      Service API, it's not a configuration file issue.)
 
     * Even with a service token, an expired user token cannot be used
       indefinitely.  There's a Keystone configuration setting that controls
@@ -136,4 +121,4 @@ To summarize, you need to be aware of:
 * Each source service: must be configured to be able to create and send
   service tokens (default is OFF)
 * Each receiving service: has to be configured to accept service tokens
-  (default is ON)
+  (default is ON) and require role verification (default is OFF)