(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.