It seems like authorization has not been addressed at all. - CDex #161

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive
    • Priority: Medium
    • US Da Vinci CDex (FHIR)
    • Financial Mgmt
    • (many)
    • Overall
    • Hide

      The OAuth scope needs to be sufficient to both POST the Task and execute the query if automated.  Because the specific resources in which the data will be exposed (and the supplemental resources - e.g. Medication, Practitioner, etc.) needed to provide context as part of the returned data) may not be known, the OAuth scope will generally be pretty broad - quite often read on Patient/* (obviously also with write on Patient/Task).  Will make this clear in the spec.

      Will also make clear that, it is up to the data source to determine if the query is appropriate and to institute appropriate filtering, regardless of the breadth of any specified OAuth scopes.

       

      Show
      The OAuth scope needs to be sufficient to both POST the Task and execute the query if automated.  Because the specific resources in which the data will be exposed (and the supplemental resources - e.g. Medication, Practitioner, etc.) needed to provide context as part of the returned data) may not be known, the OAuth scope will generally be pretty broad - quite often read on Patient/* (obviously also with write on Patient/Task).  Will make this clear in the spec. Will also make clear that, it is up to the data source to determine if the query is appropriate and to institute appropriate filtering, regardless of the breadth of any specified OAuth scopes.  
    • Bob Dieterle / Laura Herrman : 15-0-0
    • Clarification
    • Non-substantive

      Comment:

      It seems like authorization has not been addressed at all. There are out-references to HRex ballot which has a one-line security and privacy section deferring to FHIR Security and SMART on FHIR.

      http://build.fhir.org/ig/HL7/davinci-ehrx/Security_and_Privacy.html

      However, the specific transactions defined in this profile do not straightforwardly align with the specifics for OAuth 2.0 details defined by SMART on FHIR. For example, how do the scopes look like for a solicited communication transaction which pushes a task and what details are included in the OAuth 2.0 scopes carried by the Access Token for such a transaction? Not addressing these basic authorization details creates a possibility for vulnerable implementations with flawed authorizaiton.

      Summary:

      It seems like authorization has not been addressed at all.

            Assignee:
            Unassigned
            Reporter:
            Mohammad Jafari
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: