-fix notes

1 files changed, 16 insertions, 16 deletions

diff --git a/core/api-challenger.rst b/core/api-challenger.rst
index be8a36c3..25c84d3e 100644
--- a/core/api-challenger.rst
+++ b/core/api-challenger.rst
@@ -29,19 +29,19 @@ The high-level flow is that an OAuth 2.0 client is first registered with the
 challenger service (via command-line). Using the command-line tool will print
 the resulting client ID to the console.
 
-  .. note::
+.. note::
 
-     The current service mandates that redirection URIs
-     start with "http://" or "https://". See issue #7838
-     for what should be done to lift this restriction.
+  The current service mandates that redirection URIs
+  start with "http://" or "https://". See issue #7838
+  for what should be done to lift this restriction.
 
-  .. note::
+.. note::
 
-     Right now, registration of a unique redirection URI is *mandatory* for
-     each client. If multiple redirection URIs are needed, it is suggested to
-     just register additional clients.  (While OAuth 2.0 would support not
-     registering fixed redirection URIs with a client, this is not recommended
-     as it would create an open redirector.)
+  Right now, registration of a unique redirection URI is *mandatory* for
+  each client. If multiple redirection URIs are needed, it is suggested to
+  just register additional clients.  (While OAuth 2.0 would support not
+  registering fixed redirection URIs with a client, this is not recommended
+  as it would create an open redirector.)
 
 Once a client is registered, that client can use the challenger service when
 it needs a user to prove that the user is able to receive messages at a
@@ -61,13 +61,13 @@ of the challenger service, adding its ``state``, ``client_id`` and
 redirect URI registered with the client. From this endpoint, the challenger
 service will return a Web page asking the user to provide its address.
 
-  .. note::
+.. note::
 
-    Challenger is a bit unusual in that the ``$NONCE`` in the endpoint URL
-    makes the authorization endpoint URL (deliberately) unpredictable, while
-    for many other OAuth 2.0 APIs this endpoint is static. However, this is
-    compliant with OAuth 2.0 as determining the authorization URL is left out
-    of the scope of the standard.
+  Challenger is a bit unusual in that the ``$NONCE`` in the endpoint URL
+  makes the authorization endpoint URL (deliberately) unpredictable, while
+  for many other OAuth 2.0 APIs this endpoint is static. However, this is
+  compliant with OAuth 2.0 as determining the authorization URL is left out
+  of the scope of the standard.
 
 When the user has filled in the form with their address, it will be submitted
 to the ``/challenge/$NONCE`` endpoint and the challenger service will send a