From 2115ac8c47dcf17eddea8f056cfdc955465b74a9 Mon Sep 17 00:00:00 2001
From: Jen Malloy <jmalloy@redhat.com>
Date: Fri, 6 Jan 2017 14:11:58 -0500
Subject: [PATCH] fixed 'a RPT' and some wording

---
 topics/overview/architecture.adoc                  | 4 ++--
 topics/service/protection/token-introspection.adoc | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/topics/overview/architecture.adoc b/topics/overview/architecture.adoc
index bfb3849096..6b5cd52348 100755
--- a/topics/overview/architecture.adoc
+++ b/topics/overview/architecture.adoc
@@ -119,9 +119,9 @@ For more information, see <<fake/../../service/protection/protection-api.adoc#_s
 
 The Authorization API is also a https://docs.kantarainitiative.org/uma/rec-uma-core.html[UMA-compliant] endpoint providing a single operation that exchanges an Access Token and <<fake/.././terminology.adoc#_overview_terminology_permission_ticket, Permission Ticket>> with a Requesting Party Token (RPT).
 
-The RPT holds all permissions granted to a client and can be used to call a resource server to get access to its protected resources.
+The RPT contains all permissions granted to a client and can be used to call a resource server to get access to its protected resources.
 
-When asking a RPT you can also provide a previously issued RPT. In this case, the resulting RPT will consist of the union of the permissions from the previously RPT and the new ones
+When requesting an RPT you can also provide a previously issued RPT. In this case, the resulting RPT will consist of the union of the permissions from the previous RPT and the new ones
 within a permission ticket.
 
 image:../../images/authz-calls.png[alt="Authorization API Overview"]
diff --git a/topics/service/protection/token-introspection.adoc b/topics/service/protection/token-introspection.adoc
index e8641bbfe8..0d15fc6bbf 100755
--- a/topics/service/protection/token-introspection.adoc
+++ b/topics/service/protection/token-introspection.adoc
@@ -8,15 +8,15 @@ There are two main use cases where token introspection can help you:
 * When client applications need to query the token validity to obtain a new one with the same or additional permissions
 * When enforcing authorization decisions at the resource server side, especially when none of the built-in <<fake/../../../enforcer/overview.adoc#_enforcer_overview, policy enforcers>> fits your application
 
-==== Obtaining Information about a RPT
+==== Obtaining Information about an RPT
 
-The token introspection is essentially a https://tools.ietf.org/html/rfc7662[OAuth2 token introspection]-compliant endpoint from which you can obtain information about a RPT.
+The token introspection is essentially a https://tools.ietf.org/html/rfc7662[OAuth2 token introspection]-compliant endpoint from which you can obtain information about an RPT.
 
 ```bash
 http://${host}:${port}/auth/realms/${realm_name}/protocol/openid-connect/token/introspect
 ```
 
-To introspect a RPT using this endpoint, you can send a request to the server as follows:
+To introspect an RPT using this endpoint, you can send a request to the server as follows:
 
 ```bash
 curl -X POST \
@@ -65,7 +65,7 @@ If the RPT is not active, this response is returned instead:
 }
 ```
 
-==== Do I Need to Invoke the Server Every Time I want to Introspect a RPT?
+==== Do I Need to Invoke the Server Every Time I Want to Introspect an RPT?
 
 No. Both <<fake/../../../service/authorization/authorization-api.adoc#_service_authorization_api, Authorization>> and <<fake/../../../service/entitlement/entitlement-api.adoc#_service_entitlement_api, Entitlement>> APIs use the
  https://tools.ietf.org/html/rfc7519[JSON web token (JWT)] specification as the default format for RPTs.