How does a client know what events are supported?

[bvdh]

Maybe we should allow him to query the supported event using a GET on the cast-url.

[isaacvetter]

Hey Bas,

Great point.

As we move events into OAuth2 scopes (per #64), a client would need to know the supported events before it learned the cast-url.

If we look to SMART for inspiration, the choices are:

1. An extension on the FHIR server's CapabilityStatement
2. A url on the FHIR server, such as .well-known/smart-configuration

Actually, SMART's existing smart-configuration json object already defines the list of supported scopes. If we address #64, we get event discovery as part of this smart-configuration thing for free. The real question is, should we consider adding an additional "capability" to the smart-configuration file?

Isaac

GET /apis/fhir/.well-known/smart-configuration HTTP/1.1
Host: www.ehr.example.com

HTTP/1.1 200 OK
Content-Type: application/json

{
  "authorization_endpoint": "https://ehr.example.com/auth/authorize",
  "token_endpoint": "https://ehr.example.com/auth/token",
  "token_endpoint_auth_methods_supported": ["client_secret_basic"],
  "scopes_supported": ["openid", "profile", "launch", "launch/patient", "patient/*.*", "user/*.*", "offline_access", "fhircast/open-patient-chart.*", "fhircast/close-patient-chart.*"],
  "response_types_supported": ["code", "code id_token", "id_token", "refresh_token"],
  "capabilities": ["launch-ehr", "client-public", "client-confidential-symmetric", "context-ehr-patient", "sso-openid-connect"]
}

[bvdh]

That would tie the event discovery to FHIR and to the authorization mechanism.
Previous discussions indicated the need for deployments that do not require authorization. FHIRcast will also be used on more DICOM oriented deployments.
A FHIRcast specific endpoint that allows discovery would make this a FHIR Cast specific element that is independent of FHIR and authorization.
We could use a subdirectory beneath the topic URI for this. E.g. /events .