Binary securityContext explanation needs to be more complete

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Normative
    • Binary
    • Hide

      Change the definition of the element to:

      Definition:
      This element identifies another resource that can be used as a proxy of the security sensitivity to use when deciding and enforcing access control rules for the Binary resource. Given that the Binary resource contains very few elements that can be used to determine the sensitivity of the data and relationships to individuals, the referenced resource stands in as a proxy equivalent for this purpose. This referenced resource may be related to the Binary (e.g. Media, DocumentReference), or may be some non-related Resource purely as a security proxy. E.g. to identify that the binary resource relates to a patient, and access should only be granted to applications that have access to the patient.

      Comment:

      Very often, a server will also know of a resource that references the binary, and can automatically apply the appropriate access rules based on that reference. However, there are some circumstances where this is not appropriate, e.g. the binary is uploaded directly to the server without any linking resource, the binary is referred to from multiple different resources, and/or the binary is content such as an application logo that has less protection than any of the resources that reference it

      Show
      Change the definition of the element to: Definition: This element identifies another resource that can be used as a proxy of the security sensitivity to use when deciding and enforcing access control rules for the Binary resource. Given that the Binary resource contains very few elements that can be used to determine the sensitivity of the data and relationships to individuals, the referenced resource stands in as a proxy equivalent for this purpose. This referenced resource may be related to the Binary (e.g. Media, DocumentReference), or may be some non-related Resource purely as a security proxy. E.g. to identify that the binary resource relates to a patient, and access should only be granted to applications that have access to the patient. Comment: Very often, a server will also know of a resource that references the binary, and can automatically apply the appropriate access rules based on that reference. However, there are some circumstances where this is not appropriate, e.g. the binary is uploaded directly to the server without any linking resource, the binary is referred to from multiple different resources, and/or the binary is content such as an application logo that has less protection than any of the resources that reference it
    • Grahame Grieve/Josh Mandel: 4-0-0
    • Enhancement
    • Non-substantive
    • STU3

      The Binary.securityContext was brought to my attention. There was confusion as to what the meaning was, how it is intended to be used, when it is appropriate to be used, and when it is redundant.

      First, calling this a securityContext is not proper, as a secuityContext is the context of an access request. This element is a pointer at a resource that has a similar security requirement. Thus this element is not context. The element name should also indicate that it is a 'similar security' relationship.

      Second, When Binary is the subject of an Observation, DocumentReference, Media, or other... Shouldn't it be made clear that those 'meta' resources are 'implied' as the place where security requirements are seated? This is to say that there is a single sentence in the Securty Considerations about DocumentReference. When one of these meta Resources point at Binary, should Binary point back at them? This circular pointers are problematic. Especially when revisions are done. Even without circular problem, what happens when the similar resource gets updated or deleted? Given that this would present circular and other issues, should we have rule that when one of these meta objects points at Binary that the securtyContext should not be populated?

      Third, It is unclear the relationship of this securityContext and the Binary.meta.security tags. Why is there a different mechanism for Binary? I understand that securityContext is pointing at 'similar' resource, and therefore is not identical concept. However the concepts of security tags is that they represent a security abstraction of the Security Requirements. Thus overall I think that this securityContext mechanism is an inappropriate duplicate pathway for what everywhre else in FHIR we use the meta security tags.

      Fourth, This seems to be well out of the 80%. Thus this should be an extension, not core.

      Recommendation alternatives:

      1. Remove the securityContext element. explain how to better use meta.security. It seems that there might be a need to convey the meta.security in the http header (might still need an X header here)

      2. Rename securityContext to similarSecurity, make it an extension, explain that it should not be populated when one of the meta resources reference it unless there is a compelling need.

            Assignee:
            Unassigned
            Reporter:
            John Moehrke
            John Moehrke
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: