tweak language

import-pnp.md

@@ -31,9 +31,9 @@ All exchanges described herein between a client and a server SHALL be secured us
 
 With each of the requests described herein, implementers are encouraged to implement OAuth 2.0 access management in accordance with the [SMART Backend Services: Authorization Guide](https://hl7.org/fhir/uv/bulkdata/authorization/index.html).  Implementations MAY include non-RESTful services that use authorization schemes other than OAuth 2.0, such as mutual-TLS or signed URLs.     
 
-When SMART Backend Services Authorization is used to authorize Data Provider to Data Consumer requests (the initial "ping" and subsequent status checks), the Data Provider will need to have its public key registered with the Data Consumer as a client and have been issued an associated `client_id` by the Data Consumer.  When SMART Backend Services Authorization is used to authorize Data Consumer to Data Provider requests (the full or abbreviated Bulk Data Export flow), the Data Consumer will need to have its public key registered with the Data Provider as a client and have been issued a `client_id` by the Data Provider. 
+When SMART Backend Services Authorization is used to authorize Data Provider to Data Consumer requests (the initial "ping" and subsequent status checks), the Data Provider will need to be pre-registered with the Data Consumer as a client so the Data Consumer can store the Data Provider's public key information (the key itself or the location of a jwks file) and assign an associated `client_id` for use in the authorization process. When SMART Backend Services Authorization is used to authorize Data Consumer to Data Provider requests (the full or abbreviated Bulk Data Export flow), the Data Consumer will need to be pre-registered with the Data Provider as a client so the Data Provider can store Data Consumer's public key information and assign an associated a `client_id` for use in the authorization process.
 
-These two registrations can be addressed in a single workflow. For example, if a Data Consumer expects a number of Data Providers to register with it, as part of the registration process the Data Consumer can request the Data Provider's public key location along with a `client_id` that has been pre-associated by the Data Provider with the Data Consumer's documented public key location. Upon completing this registration, the Data Consumer can issue the Data Provider a `client_id` for use in its authorization requests.  
+These two registrations can be addressed in a single workflow. For example, if a Data Consumer expects a number of Data Providers to register with it, as part of the registration process, the Data Consumer can request a Data Provider's public key information along with a `client_id` that has been associated by the Data Provider with the Data Consumer's documented public key information. Upon completing this registration, the Data Consumer can issue the Data Provider a `client_id` for use in its authorization requests. 
 
 ### Request Flow