FHIR Chat · fhircast-docs / Issue #64 expand `fhircast` OAuth scope t... · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #64 expand `fhircast` OAuth scope t...

Github Notifications (FHIRcast) (Mar 05 2019 at 14:35):

isaacvetter milestoned Issue #64(assigned to isaacvetter)

At the January, 2019 FHIR Connectathon in San Antonio, @bvdh made the excellent point that we could re-use the SMART on FHIR OAuth2 scope format in FHIRcast to better enable and repesent granular context synchronization authorization.

SMART says this, for Clinical Scope Syntax

Expressed in EBNF notation, the clinical scope syntax is:
clinical-scope ::= ( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )`

Extending the existing fhircast scope, a reasonable correlary could include the specific events (from the Event Catalog) and the discrete authorization to receive notification versus the ability to request context changes for that specific event. Like so:

scope ::= ( 'fhircast' ) '/' ( event | '*' ) '.' ( 'read' | 'write' | '*' )`

So, for example a synchronizing app could request and be authorized to receive the open-patient-chart notification with this OAuth2 scope:

fhircast/open-patient-chart.read

Similarly, the same app would be authorized to request context a context change event of open-patient-chart with this scope:

fhircast/open-patient-chart.write

Alternatively, a full featured FHIRcast app, could simply be authorized with a wildcard scope of:

fhircast/open-patient-chart.*

or:

fhircast/*.read

or, even:

fhircast/*.*

Any thoughts, feedback, additional considerations for this possible change? @bvhd - did I represent your idea accurately?

Github Notifications (FHIRcast) (Apr 30 2019 at 21:02):

isaacvetter commented on Issue #64

Duplicate of Negative ballot issue #127

Github Notifications (FHIRcast) (Sep 10 2019 at 19:56):

isaacvetter closed Issue #64 (assigned to isaacvetter):

At the January, 2019 FHIR Connectathon in San Antonio, @bvdh made the excellent point that we could re-use the SMART on FHIR OAuth2 scope format in FHIRcast to better enable and repesent granular context synchronization authorization.

SMART says this, for Clinical Scope Syntax

Expressed in EBNF notation, the clinical scope syntax is:
clinical-scope ::= ( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )`

Extending the existing fhircast scope, a reasonable correlary could include the specific events (from the Event Catalog) and the discrete authorization to receive notification versus the ability to request context changes for that specific event. Like so:

scope ::= ( 'fhircast' ) '/' ( event | '*' ) '.' ( 'read' | 'write' | '*' )`

So, for example a synchronizing app could request and be authorized to receive the open-patient-chart notification with this OAuth2 scope:

fhircast/open-patient-chart.read

Similarly, the same app would be authorized to request context a context change event of open-patient-chart with this scope:

fhircast/open-patient-chart.write

Alternatively, a full featured FHIRcast app, could simply be authorized with a wildcard scope of:

fhircast/open-patient-chart.*

or:

fhircast/*.read

or, even:

fhircast/*.*

Any thoughts, feedback, additional considerations for this possible change? @bvhd - did I represent your idea accurately?

Last updated: Apr 12 2022 at 19:14 UTC