Proposed update to Secpriv-module.html 6.0.5.1 Authorization and Access Control  Use case: A FHIR server should ensure that API access is allowed for authorized requests and denied for unauthorized requests. Approach: Authorization details can vary according to local policy, and according to the access scenario (e.g. sharing data among institution-internal subsystems vs. sharing data with trusted partners vs. sharing data with third-party user-facing apps). In general, FHIR enables a separation of concerns between the FHIR REST API and standards-based authorization protocols like OAuth. For the use case of user-facing third-party app authorization, we recommend the OAuth-based SMART protocol see Security: Authentication as an externally-reviewed authorization mechanism with a real-world deployment base - but we note that community efforts are underway to explore a variety of approaches to authorization.  Resource Servers MUST enforce the authorization associated with the access token. This enforcement includes verification of the token, verification of the token expiration, and might include using introspection to verify the token has not been revoked. This enforcement includes constraining results returned to the scopes authorized by the access token. The Resource server might have further access controls beyond those in the token to enforce, such as Consent or business rules. For further details, see Security: Authorization and Access Control. 6.0.5.1.1 Query Parameters Considerations    Proposed update to security.html 6.1.0.5 Authorization/Access Control  .... The rules behind the access control decision are often very complex, and potentially depend on information sourced from: Client, such as user identity, user role, location, level of assurance Resource, such as confidentiality, sensitivity, type of data, date ranges covered by the data, author of the data Patient, such as the patient identity, patient relationship to the user, patient consent policies Context of the transaction, system identity, time-of-day,  token expiration, token scope,  purpose of use, workflow state, and transport security   Proposed update to the security checklist   6.1.0 FHIR Security  FHIR Infrastructure  Work Group    Maturity Level: 4    Standards Status: Trial Use Fast Healthcare Interoperability Resources (FHIR) is not a security protocol, nor does it define any security related functionality. However, FHIR does define exchange protocols and content models that need to be used with various security protocols defined elsewhere. This section gathers all information about security in one section. A summary: Time Keeping - all clocks should be synchronized using NTP/SNTP, and the design of the system should be robust against a system clock with the wrong value 2. Communications Security - all exchange of production data should be secured using TLS (e.g., https)+*, following  [BCP 195] ( https://tools.ietf.org/html/bcp195)*+ 3. Authentication - Users/Clients must be authenticated. For web-centric, OAuth is recommended. When using OAuth, a profile of OAuth will be needed. Consider use of Smart-On-FHIR  where appropriate.  4. Authorization/Access Control - FHIR defines a Security Label infrastructure to support access control management. FHIR may also define a set of resources to administer access control management, but does not define any at present 5. Audit - FHIR defines provenance and audit event resources suitable for tracking the origins, authorship, history, status, and access of resources 6. Digital Signatures - FHIR includes several specifically reserved locations for digital signatures 7. Attachments - FHIR allows for binary resources and attachments. These have their own concerns 8. Labels - FHIR allows for set of security related tags that affect the way resources are handled 9. Data Management Policies - FHIR defines a set of capabilities to support data exchange. Not all the capabilities that FHIR enables may be appropriate or legal for use in some combinations of context and jurisdiction (e.g. HIPAA, GDPR). It is the responsibility of implementers to ensure that relevant regulations and other requirements are met 10. Narrative - Care must be taken when displaying the narrative from FHIR resources 11. Input Validation - Validate all input received from other actors to assure the data is well formed and does not contain content that would cause unwanted system behaviour. Testing ensures that the input is not susceptible to data input validation errors by using techniques such as fuzzing, invalid input attacks, and injection attacks. 12. When using OAuth, consider the draft   [Best-Current-Practice for OAuth] ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics ) Time critical concerns regarding security flaws in the FHIR specification should be addressed to the FHIR email list  for prompt consideration.