diff --git a/README.md b/README.md
index a1a85507..5214f7aa 100644
--- a/README.md
+++ b/README.md
@@ -521,9 +521,10 @@ For example:
 authorization {
   PASS: abcdefghijklmnopqrstuvwxwz0123456789
   users = [
-    {user: alice, password: foo, permissions: $ADMIN}
-    {user: bob,   password: bar, permissions: $REQUESTOR}
-    {user: joe,   password: $PASS}
+    {user: joe, password: foo, permissions: $ADMIN}
+    {user: alice, password: bar, permissions: $REQUESTOR}
+    {user: bob,   password: $PASS, permissions: $RESPONDER}
+    {user: charlie, password: bar}
   ]
 }
 ```
@@ -545,7 +546,7 @@ authorization {
 }
 ```
 
-Here is an example authorization configuration that defines three users, two of whom are assigned explicit permissions.
+Here is an example authorization configuration that defines four users, three of whom are assigned explicit permissions.
 
 ```
 authorization {
@@ -557,6 +558,10 @@ authorization {
     publish = ["req.foo", "req.bar"]
     subscribe = "_INBOX.>"
   }
+  RESPONDER = {
+      subscribe = ["req.foo", "req.bar"]
+      publish = "_INBOX.>"
+  }
   DEFAULT_PERMISSIONS = {
     publish = "SANDBOX.*"
     subscribe = ["PUBLIC.>", "_INBOX.>"]
@@ -564,20 +569,23 @@ authorization {
 
   PASS: abcdefghijklmnopqrstuvwxwz0123456789
   users = [
-    {user: alice, password: foo, permissions: $ADMIN}
-    {user: bob,   password: bar, permissions: $REQUESTOR}
-    {user: joe,   password: $PASS}
+        {user: joe, password: foo, permissions: $ADMIN}
+        {user: alice, password: bar, permissions: $REQUESTOR}
+        {user: bob,   password: $PASS, permissions: $RESPONDER}
+        {user: charlie, password: bar}
   ]
 }
 ```
 
-Since Alice is an ADMIN she can publish/subscribe on any subject. We use the wildcard “>” to match any subject.
+Since Joe is an ADMIN he can publish/subscribe on any subject. We use the wildcard “>” to match any subject.
 
-Bob is REQUESTOR and can publish requests on subjects "req.foo" or "req.bar", and subscribe to anything that is a response ("_INBOX.*").
+Alice is a REQUESTOR and can publish requests on subjects "req.foo" or "req.bar", and subscribe to anything that is a response ("_INBOX.>").
 
-Joe has no permission grant and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the `default_permissions` entry inside of the `authorization` configuration block.
+Charlie has no permissions granted and therefore inherits the default permission set. You set the inherited default permissions by assigning them to the default_permissions entry inside of the authorization configuration block.
 
-Note that `_INBOX.>` subscribe permissions must be granted in order to use the request APIs in Synadia supported clients. If an unauthorized client publishes or attempts to subscribe to a subject, the action fails and is logged at the server, and an error message is returned to the client.
+Bob is a RESPONDER to any of Alice's requests, so Bob needs to be able to subscribe to the request subjects and respond to Alice's reply subject which will be an _INBOX.>.
+
+Important to note, NATS Authorizations are whitelist only, meaning in order to not break request/reply patterns you need to add rules as above with Alice and Bob for the _INBOX.> pattern. If an unauthorized client publishes or attempts to subscribe to a subject that has not been whitelisted, the action fails and is logged at the server, and an error message is returned to the client.
 
 ### TLS