Merge branch 'issue/351-card-summary' of github.com:cds-hooks/docs into issue/351-card-summary

Author: kpshek

docs/specification/1.0.md

@@ -14,7 +14,6 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 This specification has the following limitations.
 
 * The specification provides options for providing a CDS Service access to the EHR's FHIR resources through use of either prefetch and/or a bearer access token to be presented to the FHIR Server.  Decisions regarding which approach to take, and details regarding how the choice is implemented, are left up to the EHR vendor/provider, as architectural considerations will come into play.
-* The specification requires that each CDS Service provider be registered (client_id, key-pair identifier) with the EHR Authorization Server, but does not dictate how registration is accomplished (e.g., dynamic vs. manual).
 * The specification acknowledges that each EHR vendor/provider will need to vet CDS Service providers and suggests that vendors/providers create a "white list" of providers deemed "safe" and/or a "black list" of providers deemed "unsafe."  Similarly, an EHR vendor/provider MAY assess the safety of active links embedded in CDS Hooks Cards returned to the EHR.  The specification does not suggest how such vetting is accomplished nor suggest factors to consider, as these judgments are dependent upon each EHR vendor's or provider's existing vetting processes and risk-management policy.
 
 ## Open API Specification
@@ -483,7 +482,7 @@ Field | Optionality | Type | Description
 ----- | ----- | ----- | --------
 `type` |  REQUIRED | *string* | The type of action being performed. Allowed values are: `create`, `update`, `delete`.
 `description` | REQUIRED | *string* | Human-readable description of the suggested action MAY be presented to the end-user.
-`resource` | OPTIONAL | *object* | Depending upon the `type` attribute, a new resource or the id of a resource. When the `type` attribute is `create`, the `resource` attribute contains a new FHIR resource to be created. For `delete`, this is the id of the resource to remove. In hooks where only one "content" resource is ever relevant, this attribute MAY be omitted for deletes only. For `update`, this holds the updated resource.
+`resource` | OPTIONAL | *object* | Depending upon the `type` attribute, a new resource or the id of a resource. When the `type` attribute is `create`, the `resource` attribute SHALL contain a new FHIR resource to be created. For `delete`, this SHALL be the id of the resource to remove. In hooks where only one "content" resource is ever relevant, this attribute MAY be omitted for deletes only. For `update`, this holds the updated resource.
 
 The following example illustrates a create action:
 
@@ -602,13 +601,13 @@ Once a CDS Service provider is selected, the EHR vendor/provider negotiates the
 
 Every interaction between an EHR and a CDS Service is initiated by the EHR sending a service request to a CDS Service endpoint protected using the [Transport Layer Security protocol](https://tools.ietf.org/html/rfc5246).   Through the TLS protocol the identity of the CDS Service is authenticated, and an encrypted transmission channel is established between the EHR and the CDS Service. Both the Discovery endpoint and individual CDS Service endpoints are TLS secured.
 
-The EHR’s authorization server is responsible for enforcing restrictions on the CDS Services that MAY be called and the scope of the FHIR resources that MAY be prefetched or retrieved from the FHIR server.  Therefore, all CDS Services to be called from within an EHR system are pre-registered with the authorization server of that EHR.  Pre-registration includes registering a CDS client identifier, and agreeing upon the scope of FHIR access that is minimally necessary to provide the clinical decision support required.
+The authorization server is responsible for enforcing restrictions on the CDS Services that MAY be called and the scope of the FHIR resources that MAY be prefetched or retrieved from the FHIR server.  If a CDS Client is satisfying prefetch requests from a CDS Service or sends a non-null `fhirAuthorization` object to a CDS Service so that it can call the FHIR server, the CDS Service MUST be pre-registered with the authorization server protecting access to the FHIR server.  Pre-registration includes registering a CDS client identifier, and agreeing upon the scope of FHIR access that is minimally necessary to provide the clinical decision support required. This specification does not address how the CDS Client, authorization server, and CDS Service perform this pre-registration.
 
 ### Trusting EHRs
 
 The service agreement negotiated between the EHR vendor/provider and the CDS Service provider will include obligations the EHR vendor/provider commits to the CDS Service provider. Some agreements MAY include the use of mutual TLS, in which both ends of the channel are authenticated.
 
-However, mutual TLS is impractical for many organizations, and because the EHR initiates the TLS channel set-up, only the CDS Service endpoint will be authenticated.  To enable the CDS Service to authenticate the identity of the EHR, CDS Hooks uses digitally signed [JSON web tokens (JWT)](https://jwt.io/).
+However, mutual TLS is impractical for many organizations, and because the EHR initiates the TLS channel set-up, only the CDS Service endpoint will be authenticated.  To enable the CDS Service to authenticate the identity of the EHR, CDS Hooks uses digitally signed [JSON web tokens (JWT)](https://jwt.io/) ([rfc7519](https://tools.ietf.org/html/rfc7519)).
 
 Each time an EHR transmits a request to a CDS Service, the request MUST include an `Authorization` header presenting the JWT as a “Bearer” token:
 ```