-
Type:
Change Request
-
Resolution: Persuasive with Modification
-
Priority:
Medium
-
FHIR Core (FHIR)
-
STU3
-
FHIR Infrastructure
-
Binary
-
2.33.3.3
-
-
Grahame Grieve/Rick Geimer: 9-0-0
-
Non-substantive
-
STU3
Existing Wording: Binary resources are not constrained, and therefore can be of any content type and encoding. Therefore, extra care needs to be taken to validate the content of the Binary resource against malicious or malformed content. For more details see?Security of Narrative.
Very often, the content of a Binary resource is sensitive, and the server should apply appropriate access control to the content. When the server itself generates the content, it implicitly knows what access control to apply. When the client provides the binary to the server itself, it uses the securityContext element (or the matching X-Security-Context HTTP header) to inform the server that the Binary resource should be treated as if it was the other resource. Typically, the other resource is a DocumentReference or similar resource that refers directly to the Binary resource, but that is not mandatory.
Comment:
Why is Binary any less constrained than any other resource (or any other resource that can contain b64 content)? How is Narrative relative to this?
Why does a server implicitly know what access control to apply?
Summary:
Binary security clarification
- is voted on by
-
BALLOT-4873 Affirmative - Elliot Silver : 2018-May-FHIR R4 INFRASRUCTURE R1
- Closed