Callback URL Verification

[ghost]

This issue concerns the initial FHIRCast subscription to a topic.

If an App is subscribing to the Hub, it transmits a callback-url (see http://fhircast.org/#synchronize). The App (Subscriber) itself is OAuth verified, and the general use-case can assume that the callback-url is for that App (Subscriber). However as the callback-url can be anything, one could potentially use the subscription as a form of broker where an App (Broker) subscribes a different App (Event Consumer) to the Hub.

The problem that arises here, is that the EventReceiver can be "anything", including an Application that has not been verified with OAuth. That could lead to the problem that sensitive data is transmitted to an unautorized App (Event Consumer).

Since the Hub already verifies the callback-url in the sense of "do you really want to subscribe to this, and can you solve my challenge -> proving that you implemented the subscription model", one possible option is that the callback responds with an OAuth-Token verifying it in the security context, and ensuring that data being sent to it, is something it is allowed to see.

This would also enable a broker pattern where one App (Broker) is responsible for matchmaking between the Hub (Event Producer) and several Subscribers (Event Consumer), while still managing verification of access though the Hub.

[isaacvetter]

Hey @RazStorm , great analysis!

This would also enable a broker pattern where one App (Broker) is responsible for matchmaking between the Hub (Event Producer) and several Subscribers (Event Consumer), while still managing verification of access though the Hub.

In such a broker pattern, it seems like the hub wouldn't actually know anything about the downstream subscribers (event consumers), specifically because the broker<-> subscriber/consumer relationship is negotiated outside the Hub<-> broker relationship. Further, the Hub-granted, OAuth2 access_token is owned by the broker and traceable to it's client_id. Sharing this access_token with the subscribers/consumers would also grant those subscribers/consumers access to the Hub's FHIR server with the broker's scopes. For these reasons, I don't think that it makes sense for the Hub to require that the broker share it's access_token with the subscribers/consumers.

I'd like to turn this issue around on you - Given that the app (subscriber not in a broker relationship), is already authenticating to the Hub when creating the subscription, why don't we remove the url verification step completely?

This url verification is required in WebSub; in part, I think, because, the initial subscription transaction isn't authenticated. So, not requiring it would be a break from WebSub.

[ghost]

Definitely an option. There still remains the risk that the Subscriber and the System specified in the callback are not one and the same. If we make this the responsibility of the Subscriber (i.e. Callback is assumed to have the exact same access rights / is the Subscriber) this is not a problem. -> I.e. verification can be removed.

[isaacvetter]

Hey @RazStorm

There still remains the risk that the Subscriber and the System specified in the callback are not one and the same.

Definitely. I think this is very likely to be different machines, but even (to your point) to also be entirely different systems. It's an important use-case.

If we make this the responsibility of the Subscriber

👍

(i.e. Callback is assumed to have the exact same access rights / is the Subscriber)

Perhaps more explicitly, callback authorization is the responsibility of the subscriber, not the hub.

I think that this makes sense to call out in the spec. I just created PR #30 adding this text:

Within FHIRcast, the client that creates a subscriptions and the server that hosts the callback url are the same entity. If these roles are split, the Hub assumes that the same authorization and access rights apply to both systems.

this is not a problem. -> I.e. verification can be removed.

This leaves us incompatible with WebSub. Is that a big deal?

[ghost]

I think #30 solves this according to the discussion :)

Concerning WebSub -> We should ask implementers if they want/need compliance with WebSub

I think that if, so far we are compatible / using the WebSub spec, and this is the ONLY thing where we break with WebSub, then verification should be kept. From an implementer perspective it takes maybe about an hour to implement the verification on client and server side. However in that case the text in index.md

Modeled after the common webhook design pattern and specifically the W3C WebSub RFC

should read

Modeled after the common webhook design pattern and is specifically compliant with the W3C WebSub RFC

To me, at least it looked like FHIRCast is modelled after the WebSub, but was not aware it is compatible.

[jkiddo]

Given that you base yourself on an existing WebSub implementation that actually follows the standard, then you've just ruined it if you won't follow the standard. I would encourage you guys to stay compatible with the standard and extend it - not break it - or the conformance to it.