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

Stream: fhircast-github

Topic: docs / Issue #64 expand `fhircast` OAuth scope to include...

Github Notifications (FHIRcast) (Feb 05 2019 at 18:31):

isaacvetter opened Issue #64

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) (Feb 05 2019 at 18:31):

isaacvetter assigned 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