Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-25810

Separate event scope checking from hub.

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Deferred (View Workflow)
    • Priority: Highest
    • Resolution: Considered for Future Use
    • Specification:
      FHIRCast (FHIR)
    • Raised in Version:
      0.1
    • Work Group:
      Imaging Integration
    • Related Page(s):
      (NA)
    • Related Section(s):
      Session Discovery
    • Grouping:
    • Resolution Description:
      Hide

      Propose to defer to later version of FHIRcast

      Show
      Propose to defer to later version of FHIRcast
    • Resolution Vote:
      Eric Martin / Bill Wallace: 8-0-0

      Description

      (Based on input from George on Zulip)
      We should allow support of alternative launch mechanisms that allow applications to be launched and subscripe using an alternative authorization scheme. In the current specification the hub is responsible for determining whether an application may be send/received. I wonder whether this should the responsibility of the hub. I suggest to to remove the authintication scopes for events and to allow each event type to have a controller that decides whether subscription is allowed. In this case only a general fhircast scope is required, the controller would check whether the subscriber can send the event. This would also require a registration and discovery mechanism.

      Existing Wording:

      Systems SHOULD use SMART on FHIR to authorize, authenticate and exchange initial shared context. If using SMART, following a SMART on FHIR EHR launch or SMART on FHIR standalone launch, the app SHALL request and, if authorized, SHALL be granted one or more fhircast OAuth 2.0 scopes. Accompanying this scope grant, the authorization server SHALL supply the hub.url and hub.topic SMART launch parameters alongside the access token and other parameters appropriate to establish initial shared context. Per SMART, when scopes of openid and fhirUser are granted, the authorization server additionally sends the current user's identity in an id_token.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              bvdh Bas van den Heuvel
              Request in-person:
              Bas van den Heuvel
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: